X'OIU.A 0 ’J 

3l . . .'eo i-.-' SCHOOL 
0^-i.ii uxiWiA 9C9'i3-B002 



NAVAL 



POSTGRADUATE SCHOOL 

Monterey, California 




THESIS 



SHIPBOARD AM>rJi;iTION MANAGEMENT SYSTEM: 

A DATABASE APPROACH 

by 

Steven L. Smith 
September 1987 

Thesis Advisor N. R. Lyons 

Co- Advisor Y. Mortagy 



Approved for public release; distribution is unlimited. 



T234387 






I i 









g ASS■^CAflcS^ rig T»^V<~PA<!^r 



REPORT DOCUMENTATION PAGE 



«fPO*T ucu^iTy Classification 

UNCLASSIFIED 



2i StCU«'t^ ClASSlHCAtlON AUThO«'Tt 



;o OCCL ASS'FiCATiON / OOwVNC«AOiNO SCnCOuU 



\b ACSTAlCTiVC MAAAINCS 



] 0»ST*liuTlON/ AvAiLAgiLlTV OF R(PO«r 

Approved for public release; 
distribution is unlimited 



4 PI«F0«V.NU 0«CAN';aTiON «{P0RT SUMBCRJS) 



S MONiIOPiNG OPGANi/ATiON «FP0«T NuV9£R(S> 



64 NAV( CF p(P(OPviNG Organization 
Naval Postgraduate School 



bo OFFICE S^MlOw 

(if 400it<4b*9) 

54 



7s NAVC OF MOmTORiNG organization 
Naval Postgraduate School 



tx AOORfSS iC-ry Sfife sna /i^CoOt) 

Monterey, California 93943-5000 



7d AOOR(SS(C<fy itsfs sr»c$ Coot) 

Monterey, California 93943-5000 



8 j navt f,^nO(No sponsoring 
organization 



Bo OF^iC£ Si^MSOw 
(If SPQit<40*t) 



9 PROCuRfcMtST .NSTkuMtNT 0( N ’ -F 'C A I iOn NUM9£R 



dc aOORFSSiC*i> Sf4Tf 4/xJ ZiPCoop; 



10 souRCf OF Funding numrfps 



PROGRAM 


PRO.ECT 


r AS< 


FlFMFNT NO 


NO 


NO 



xNORk. s^NiT 

ACCfSS'ON NO 



T ’.c iffu/'f> C'4Ui Iff 4 

SHIPBOARD AMMUNITION MANAGEMENT SYSTEM: A DATABASE APPROACH 



•; PfRSONA. AuTmCRIS) 








Sm; 


ith, Steven L. 






}j •>-'r CF RfPOR’ 


^ V( COVERED 


»4 DAT( OF RfPQRT iffs, MOOfl^ DSf) 


’S PACt CO^NT 


Masrer'i Tnesis 


» 00 V ’ '' 


198“ Sentember 


187 








COSA^ CODtS 1 


‘ £.D 


I GROlP ' SoP GROk P j 




1 ^ 1 







19 Su0 FC’ ’fRVS ori fSvtrit >f nrffk44/> 41XJ Of 0<0< « Owmo#') 

Ammunition Management, Ammunition Inventory Management, 
Database Inventory System, Automated Inventory System 



9 A0S*R-AC^ (Co<^f»nwf o/’ 04CtiJ4'> 4<XJ by tvcx* nomotn 

This thesis concerns the analysis, design, and partial implementation of a 
software package to automate the present manual system of conventional ammunition 
management onboard most ships of the U.S. Na\w. Structured analysis and design 
techniques are utiiized In the developcmcnt and approximately one quarter of the 
application programs have been implemented. 

The system is designed for stand alone operation on an IB.M compatible 
microcomputer using the relational database package dBase III Plus by Ashton-Tate. 

Follow-on work would consist of completing the application programs, select a 
pilot vessel and install the system, collect user comments, and modify the system as 
necessary. 



.0 0 S'»‘ 3 U''ON- AvAiUkilllTr O* A»SI*ACT 

ill . NClASSilif OriNl'MlIC 0 O SAMJ AS DD^'C uSMS 



J1 ASStAACT SlCUAllT ClASSiMCAIION 

UMCLASSIFIED 



Ji4 SAV{ O* B(S»ONS'll{ ISO'VIOUAI 



ZZb AftsCodt) 

(408> 646-2666 



ZZc OFHU symbol 
54Lb 



OOfORM 1473. MMAR 



BJ APR ^4y bt t«^4wtTtd 

Ail OTbtf S 19 ObtOi«tt 



SKuRiTy Classification of This pacc 



1 



Approved for public release; distribution is unlimited. 



Shipboard Anununition Managehient System: 
A Database .Approach 



by 



Stesen L.^Smith 
Lieutenant, L'nitc(l States Navy 
B.S.. Washington State University, 1979 



Submitted in partial fuinilment of the 
requirements for the degree of 



.MASTER OF SCIENCE IN INFOR.MATION SYSTEMS 



from the 

NAVAL POSTGIUADUATE SCHOOL 
September 1987 



ABSTRACT 



This thesis concerns the analysis, design, and partial implementation of a 
software package to automate the present manual system of conventional anrmur.ition 
managem.ent onboard most ships of the U.S. Navy. Structured analysis and design 
techniques are utilized in the developement and approximately one quarter of the 
application programs have been implemented. 

The system is designed for stand alone operation on an IBM compatible 
nticrocomputer using the relational database package dBase III Plus by Ashton-Tate. 

Follow-on work would consist of completing the application programs, select a 
pilot vessel and install the system, collect user comments, and modify the system as 
necessary. 
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I. INTRODUCTION 



A continuous chain of ammunition, fuel and equipment is the life blood of a 
military organization in wartime. The incredible speed and atti-ition of modern warfare 
requires the proper placement, both in type and quantity, of ammunition in peacetime 
to m.eet the expected demands of a major conflict. 

The world-wide commitments of the United States and its allies dictate a logistics 
system which is exceedingly complex. The global stockpiling of conventional 
ammunition is perhaps one of the more complex problems military planners m.ust 
solve. Not only does this stock require verx’ accurate accounting and physical security, 
but it is perishable in nature and its serviceability must be continually reviewed. During 
the Vietnam war. Na\y ammunition procurement reached a high of S98S million 
[Ref 1: p. 24] with world-wide inventories valued at approximately S7 billion dollars. It 
was during this period that the Chief of Naval Operations directed the establishment of 
a single point of reference within the N'a\y for conventional ammunition management. 
The Chief of Naval .Material was given the responsibility for the establishment of a 
Conventional Ammunition Integrated .Vlanagement System (CALMS). One of the 
prime operational purposes of CALMS [Ref 2], was to improve the quality of 
ammunition stock status reaching higher echelon logistics planners. CALMS is the 
point of reference regardless of inventory management or ownership responsibilities. 
Perhaps most important to the end-user, it was the stated policy of CALMS to 
minimize the reporting burden of field activities. For example, ships were to report 
expenditure and inventorx' information to CAIMS only, and CAIMS would further 
distribute the information as necessary to other interested parties. 

CAIMS was established and is directed by the Na\y Ship's Parts Control Center 
(SPCC) at .Mechanicsburg, PA. Program guidance is promulgated by SPCC [Ref 3] 
and is further defined with specific implementing and reporting instructions in Fleet 
Comjnander instructions [Refs. 4.5], 

The program has been successful in many respects, however several audits in the 
early 1980's conducted by the US General Accounting Office (GAO) and the Naval 
Audit Service found significant discrepancies between on-site local records and CALMS 
data. This brought into question the Navy's ability to maintain accountability for it's 
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S7 billion plus ammunition inventor}' [Refs. 6,7,8]. Future negotiations for ammunition 
appropriations depend on the mutual assurance of a credible inventor}' management 
system. The timely and accurate reporting from the hundreds of field activities and 
ships is critical therefore to the success of the overall system. 

Although C.A.I.V1S as a whole has become highly automated, linking SPCC, the 
major stock points, and other organizations in the logistics hierarchy, the majority of 
end-users enjoy no such capabilities. 

.y. PURPOSE 

This thesis will suggest a method to automate the present manual record keeping, 
report writing, and inventory control procedures in use on nearly all US Navy surface 
and submerged combatants. It is felt that the present procedures contribute to the high 
error rate in transaction reporting and inventory management. For activities that can 
dedicate an individual or individuals to the sole task of properly keeping the necessary 
records and generating the required reports, automation may seem unnecessary'. 
However, the proposed system will increase the accessibility of ammunition and 
inventory information, greatly reduce storage requirements, and reduce the time 
required to manage the system. Therefore any activity should benefit and avail itself of 
a properly designed system that satisfies the functional requirements. The fact is, most 
ships do not have the luxury of assigning an individual to study this system and 
become an expert. The list of important administrative and record keeping tasks on a 
typical naval vessel often exceeds the crew size by a large margin. This thesis then will 
also attempt to lessen the administrative burden on weapons department, and in some 
cases supply department, personnel who are charged with the responsibility of 
conventional ammunition management. 

This automated software solution shall be called the Shipboard Ammunition 
.Management System (SA.MS) and shall encompass all areas of routine ammunition 
managem.ent. The scope of this thesis will carry the project through the analysis, 
design, and partial implementation of critical areas of the application programs. 
Complete implementation and additional research shall be discussed in Chapters 5 and 
6. It was particularly desired to start the implementation in this thesis because many 
good ideas never seem to bridge the void between paper and code on a project as 
restricted in time as a thesis necessarily is. 
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B. MOTIVATION 



The impetus for this project came from the- observation of the need by this 
author during several tours of duty on submarines of the Atlantic and Pacific Fleets. 
•Although the quantities of conventional ammunition carried onboard submarines is 
considerably less, in quantity and variety, chan most surface combatants, it was still 
obvious chat an automated system could greatly improve the efficiency of the system. 
.As discussed earlier, the many necessary administrative functions onboard a vessel 
generally do not decrease in proportion to crew size, so many smaller vessels suffer 
more in this respect. .Additionally, enlisted rate training is particularly brief in the areas 
of conventional ammunition management [Ref 9: p. 12-1]. Officer training is 
essentially nil in this area also. Therefore, the accurate and timely reports that CAIMS 
requires to maintain an accounting of Nacy assets is being furnished by people with 
little time or training to become proficient in yet another adininistrative task.. Now 
obviously, shipboard personnel are using the available publications and are supplying 
reasonably accurate information to the CAIMS system otherwise there would be much 
higher level attention to this problem. This author contends that SA.MS will make 
more time available for important operational and weapons employment training. 

.Automating a previously manual task requires consideration of the operator's 
ability to operate the system by back up methods when necessary. The automated 
system must not be so abstract and "automatic" that the manual skills and knowledge 
of the underlying procedures are forgotten. Therefore, any system of this type must be 
instructive as well as functional. Such a system has elements of an expert system. It is 
developed by previous users who have acquired the proper education and training to 
implement a software solution, and pass on that expertise to the current users while 
satislying the functional requirements. This type of user interface could become 
e.xtremcly tedious if the system is used frequently and so a balance must be struck 
between elTicieny of data entry and the degree of explanatory' information. 

Lastly, it is unfortunate that the very personnel who require relief from 
administrative burdens often have neither the time or training to affect the change to 
automation. Thus it is particularly appropriate that shore commands and the Naval 
Postgraduate School solve these types of problems in addition to more basic research. 
The making available of time to train in relevant warfare topics is at the heart of 
current drives to reduce administrative and paperwork tasks within the Navy. 



C. CHAPTER OUTLINE 

Chapter I has discussed the importance of accountability and inventor>' 
management of conventional ammunition within the Navy. A broad discussion of the 
logistics hierarchy has highlighted the necessity of accurate and timely information 
llowing up from the hundreds of field activities and ships. The purpose of this thesis 
was stated to be a software application package to automate the tedious and complex 
manual record keeping required at the fleet end-user level. 

Chapter 2 will describe the present manual system of ammunition management in 
detail and point out the problems inherent in these procedures. The references for the 
manual system will be examined to illustrate the difficult task of interpreting this large 
volume of often overlapping documentation. Examples of data redundancy will be 
examined to help understand why internal record keeping is more complex than it 
should be. Finally, the lack of standardized procedures for the end-user management of 
ammunition will be discussed in light of the improvements available from a 
standardized software application. 

Chapter 3 describes the methodology for the developement of a software solution 
to the problem. The analysis phase is considered in detail and system data elements are 
identified. A tailored Data Element Dictionary (DED) is developed and Data Flow 
Diagrams (DFDs) illustrate the proposed system as levels of process descriptions. 
Finally, the advantages of a database solution and normalization theory are discussed. 

Chapter 4 provides the technical details of the relations, fields, indexes and keys 
with respect to relational database design and normalization. The transition from 
logical to physical process descriptions takes place with the developement of structure 
charts for the system. The qualities of good modular design are discussed and the 
effects programming in dBase III Plus has on these qualities. 

Chapter 5 discusses the application code that has been implemented for this 
thesis and the reasons for selecting these programs. Coding design decisions and style 
are discussed in light of the potential end-users and frequency of use. System 
expandability and flexibility are highlighted. 

Chapter 6 contains reconomendations for future research and comments and 
conclusions. 

The .Appendices will consist of: 

a. Data Flow Diagrams 

b. Data Element Dictionary 

c. Program Directory 
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d. Structure Charts 

e. Program Code Listin 

f. Programs Diskette 



II. PRESENT MANUAL AMMUNITION MANAGEMENT / PROBLEMS 



Naval units are required to maintain records and submit reports which provide 
accountability of conventional ammunition and allow reconcilliation of Xa\w 
ammunition assets world-wide. 

.\s a preface to a discussion of the inventory control procedures, it is worthwhile 
to review the item control methods used within the Navy. The military services 
participate in the Federal Cataloging System [Ref 10: sec. 2032]. Most NATO 
countries also participate in the United States Item Identification Code, for military 
standardization purposes, under NATO Standardization Agreement 3151 [Ref 10: sec. 
2035]. .All conventional ammunition items at the end-user level should conform to the 
Federal Cataloging System. These items are assigned a National Stock Number (NSN) 
by the Defense Logistics Services Center (DLSC) at Battle Creek. .Vlichigan. 

An NSN is a 13-digit stock number, see Figure 2.1 , and is composed of a 4-digit 
Federal Supply Classification (FSC) followed by a 9- digit National Item Identification 
Number (NTIN). An FSC describes a "family" of items of supply sharing such common 
characteristics as nomenclature, end application, or physical construction. For example, 
the FSC 1345 is the bomb "family" of conventional ammunition. 



1345 



00 - 1234567 

' Frmi 

TIFR 



Figure 2.1 National Stock Number breakdown. 

The first two digits of the NTI.N are the National Codification Bureau (NCB) code, and 
are essentially a country code (and in some publications referred to as that), within the 
N.ATO framework. The United States is assigned the NCB "00" and since it is always 
part of the NTIN we will no longer distinguish it from the NTIN. .A NTIN uniquely 
identifies an item in the Federal Cataloging System. 
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Item identification unfortuneately gets a bit more complicated. The Department 
of Defense (DoD) has established a Department of Defense Ammunition Code 
(DODAC). which is an S-digit code consisting of a 4-digit FSC (same as previously 
mentioned), and a 4-digit DoD Identification Code (DODIC). See Figure 2.2 . 



1345^ - AOll 

'uuuri 

I5U15A'C 



Figure 2.2 Department of Defense Ammunition Code. 



To proceed further, the Navy Ship's Parts Control Center (SPCC) has assigned a 
4-digit Navy Ammunition Logistics Code (NALC) to certain end round missiles and 
torpedoes. The NALC is sinuiar to the DODIC except that it is assigned by SPCC 
rather than DLSC. See (Ref 11]. NALC's are listed in the Stock List of Navy 
Ammunition, TWOIO-AA-ORD-OIO [Ref. 12], along with the DODIC if a NALC has 
not been assigned. 

A particular item will have a unique FSC, a unique NUN, but may have either a 
N.ALC or a DODIC. Figure 2.3 may help illustrate this point. 



FSC + NUN = NSN 

FSC + DODIC/NALC = DODAC 



Figure 2.3 Identification Number Composition. 

Until recently, Na \7 ammunition items were tracked by NALC vice NUN, and it 
is obvious that since a N.ALC does not uniquely describe an item but a group of verv' 
similar itemis, accurate stock knowledge was not possible for the end-user accounts. 
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Items of the same XALC DODIC arc normally functionally compatible, but may have 
small differences. For example, NALC .^015 is for 12 gauge shotgun shells, 00 buck, 
but one NHN is for a shell with paper cases and one has plastic cases. Apparently 
recognizing the lack of accuracy that results from NALC reporting. SPCC is now 
emphasizing NUN reporting on all documents. An automated system should enforce 
this more logical approach, while still maintaining the NALC identity because it is still 
widely used for referring to an ammunition type. The Stock List of Na\w Ammunition, 
n'.entioned earlier, contains cross referencing for this purpose, as well as being the 
prime source of generic infor.mation about conventional ammunition within the Navy. 
Coast Guard, and Marine Corps. It is updated regularly on microfiche and held by all 
activities with Navy ammunition. 

To conclude this discussion of item identification, two additional terms are 
important. .Ammunition Lot Numbers (ALN'.s) or just Lot Numbers, are assigned by 
loading, manufacturing, or assembly activities to identify homogeneous material that 
should function in a "near identical" manner. The lot number is also important to allow 
tracking, to maintain performance and surveillance records, and allow suspension or 
recall if necessary. New items are assigned ALN's in accordance with .MILSTD-1 168A, 
however much older anununition is still in the inventory v\ith less uniform lot number 
formats. Finally, serial numbers are assigned to high value or special interest items to 
allow individualized tracking. 

.A. INVENTORY RECORDS 

Three types of record cards are used onboard ships for inventory control. 

1. Master Stock Record Card 

The Ammunition .Vlaster Stock Record Card, N'AVSL’P Form 1296, Figure 
2.4 , is kept for each NALC, 'DODIC carried onboard. The card provides a history of 
the transactions that have occured effecting the quantity or status of that item. 
Changes to the quantities in the inventory can take place by receipts, issues, or 
expenditures. Expenditures can occur due to combat operations, training, test and 
evaluation, exercises, and other reasons. Each form of transaction has a one character 
code, the Transaction Code, that describes it. These codes are explained and listed in 
the SPCC CAIMS manual [Ref 3: p. 8-5-35). 

If material is received or issued it will have a corresponing document number, 
which is composed of the activity's Unit Identification Code (LTC). the 4-digit julian 
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AMMUNITION MASTER STOCK RECORD CARD 




Figure 2.4 Ammunition Master Stock Record Card. 
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date, and a 4-digit serial number. The serial numbers are assigned sequentially and the 
recommended range is 8000 to S90Q. They may then repeat, however used in 
conjunction with the julian date, a requisition can be uniquely identified. See Figure 2.5 



M00253 6128 8125 

__i i_i I ] 

UIC Julian serial 
date number 

Document Number ^ 



Figure 2.5 Document Number. 

Reclassification of onboard inventory items may occur when SPCC, or the 
Inventory Manager or Technical .Manager, determines that a particular lot of 
amaiiunition should be suspended, used in a limited ftshion, or considered 
unserviceable. Fleet users are notified of such changes by Notices of Ammunition 
Reclassification (NAR) messages. Approximately annually, all effective NAR's are 
incorporated into NAVSEA Publication TWO24-AA-ORD-010, Ammunition - 
Unserviceable, Suspended, and Limited Use [Ref 13]. A particular item's degree of 
serviceability is described by its one character Condition Code, all of which arc fully 
discussed in Appendix C to Reference 13 . 

On the .VI aster Stock Record Card, the on-hand balances are subdivided 
among the various condition codes that the activity holds for a particular NALC. 
Condition Code .Alpha, unrestricted, is naturally the most common. 

The Naval Sea Systems Command (NAVSEA) publishes allowance lists for 
each vessel which depend on its type and configuration. The lists contain ammunition 
type and quantity authorized, as well as the quantity of certain NALCs that may be 
used for training. The master record card is used to record these numbers and the 
computed unexpended training allowance remaining for the fiscal year. 

.Any changes in quantities or condition codes require that an Ammunition 
Transaction Report (.ATR) be submitted. This report will be more fully described later. 
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but the Master Stock Record Card is used to associate the ATR number with the 
particular transaction line item on the card. 

Finally, various other codes are recorded on the card which are obtained from 
one of several references; 

1. Packaging Remarks: References 12 or 14 

2. Logistics Code-NALC: References 12 or 14 

3. COG-Ccgnizance Symbol: Reference 12 

4. MCC-Material Control Code: Reference 12 

5. DOT-Department of Transportation Hazardous Material Code: Reference 14 

6. NHEEW-Xet E.Kplosive Weight; References 12 or 14 

C.G. Haz. Cl. -Coast Gaurc Hazardous .Material Class : Reference 14 

2. Lot/ Location Card 

The Ammunition Lot Location Card. NAVSUP Form 1297, Figure 2.6 , 
is completed for each lot number within a NTIN. There are only a few new concepts on 
this card tlutt have not been previously e.xplained, so the explanation will be brief. The 
consignor consignee is the shore activity or operating unit to which the issue was made 
or from which the item component was received. This card contains much information 
previously entered on the .Master Stock Record Card. 

3. Serial/ Location Card 

The Ammunition Serial, Location Card. N.AVSL'P Form 1356. Figure 2.7 . is 
completed for items that require SLIT tracking. Serial,' Lot Item Tracking (SLIT) is a 
system whereby certain ammunition items are designated for increased tracking and 
surveillance. These items may require identification by lot number, serial number, or 
both when reporting transactions. This distinction is indicated by the .Vlaterial Control 
Code(.MCC): 



Items that do not require SLIT reporting w'ill not have an MCC assigned. MCC Bravo 
ammunition is adequately documented on the Lot 'Location Card. Items with MCC 
Charlie and Echo require individualized tracking with the .Ammunition Serial, Location 



MCC 

B 

C 

E 



Reports 
Lot Number 
Item Serial Number 
Lot and Item Serial .Number 



Card. 
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Figure 2.6 Ammunition Lot'Location Card. 
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Figure 2.7 Ammunition Serial/Location Card. 
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The only new item here is the Maintenance Due Date (MDD), which is the month and 
year of the component's next scheduled maintenance. MDD's are assigned to MCC 
Charlie and Echo items only. Figure 2.8 may help to illustrate the relationships 
between the various stock cards. 

4. Discussion of Inventory Record 

.As Figure 2.S demonstrates, normally 2 and occasionally 3 of the stock record 
card types are required to describe an ammunition item. With no other device 
available, the .Master Stock Record Card must hold all the transaction information for 
every transaction (i.e.. document number, type, quantity, etc.). It must hold all of the 
allowance information, or you would have to reference the Allowance List each time 
you needed that information. It holds much generic data about the item which does 
not change regardless of transactions or quantity in the inventory. The alternative 
however would be to look up information, each time you were interested, in at least 
four very voluminous publications. 

The Lot Location card subdivides each NUN by lots, and much information 
is repeated. The only new data items are the lot numbers. The Serial'Location cards 
likewise duplicate data. 

It is quite obvious that maintaining all the required records for even a small 
ship's inventory, say at least 40 NALCs, would be extremely tedious. A large vessel 
with perhaps hundreds would demand full time attention. It is this author's experience 
that much of the repetitive information would not get entered properly, and the initial 
construction of a set of cards would be an onerous task. .Multiplying those man-hours 
for all the ships involved results in considerable non-operational training time. 

Ideally the inventory records should contain information that deals only with 
that particular batch of ammunition, namely: 

1. NUN - what is it? 

2. Condition Code - what can it be used for? 

3. Activity Classification Code - who is it for? 

4. Quantity - how many are there? 

5 . Storage Location - where is it? 

6. .MDD - when docs it need maintenance? 

7. Lot Number - what lot is it? 

S. Serial Number - which one is it? 
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Figure 2.8 Ammunition Stock Card Relationships. 
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This information can no[ be looked up in a publication because it deals with the 
particular articles at hand. Other information listed on the stock cards is of general 
nature and can be looked up. indicating that we could locate it in one central place and 
reference it when needed. Therefore we would not have to repeat it on every card. This 
is one of the important concepts of automation that can be used in many ways as 
chapter 3 will demonstrate. 

B. REQUISITION. TURN-IN/TRANSFER, RECEIPT 
1. Background 

Naval vessels are required to maintain 100% of their authorized allowance on 
board or on order, so as to be ready for immediate combat operations. Certain 
exceptions apply which are spelled out in the SPCC CAIMS manual [Ref 3; p. 8-2-2j, 
and may be modified by fleet commander instructions [Ref 4,o]. Reasonableness 
dictates how small an order should be placed to satisfy these requirements, of course, 
where ammunition is concerned, too much is better than not enough! 

A few more definitions are appropriate at this point. Activity Classification 
Codes (.A.CC) describe basically who the ammunition is for. It may be carried by a ship 
to satisfy its own offensive and defensive armament needs, in which case it is ACC 
Alpha ammunition. However, other ammunition could be carried for embarked 
Marines, aviation units, or for underway replenishment of other ships. Each of these 
other recepients causes the ACC to be different. Most medium to small ships and 
submarines only cariy ammunition for their own use, but most large ships have 
ammunition on board for other purposes and thus they must account for it separately 
(ie- a separate deck of inventory cards). This makes the ACC an essential data element 
for each ammunition record. Chapter 8 of the CAIMS manual [Ref 3: p. 8-5-34], lists 
and describes all of the ACC codes. 

.Associated with the concept of ACC, are the three types of allowance lists a 
ship may have. A Shipfill Allowance List authorizes the quantities and types of 
ammunition for own ship's use. A .Vlission Load Allowance List is that ammuniton 
carried to support associated ships or aircraft squadrons; usually aircraft carriers and 
tender type ships. A Cargo Load Allowance List is normally held by designated cargo 
or logistic type ships ( AE, AOE, .AOR, etc.) for replenishment of other vessels. 

-All naval vessels, as well as the other services and many government agencies, 
submit requisitions and transaction reports in Military Standard Requisitioning and 
Issue Procedures (MILSTRIP) format [Ref 3: Chapter 8]. This system serves to 
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standardize procedures for efficiency and economy. It allows machine readable logistics 
traffic by specifying data elements, codes, and formats. Until recently, transaction 
reporting was done in normal narrative message format which had to be transcribed to 
MILSTRIP format at a shore activity with .-\DP capability. New instructions from 
SPCC [Ref 3], and those still in production at fleet headquarters, now direct a format 
that IS machine readable, reducing the chance of error in transcription or key punching. 
SPCC is linked, via .ADP equipment and teleconununications with all major stock 
points, many minor stock points, and other logistics organizations. Ships submit 
manual requisitions or send messages which arc entered into the CAIMS at a shore 
acti.ity. 

The Defense .Automatic Addressing System (D.AAS), with primar.' location in 
Dayton. Ohio, is a telecommunications system which was designed to efiectively route 
logistics traffic from all the services. DAAS computers can receive messages, perform 
some format error checking, determine the addresses, and route them over the quickest 
path to their destination. DA.AS functions over the .Automatic Digital Network 
(.AL'TODIN). The message format that is acceptable to D.A.AS is slightly different, and 
the requirements for use more restrictive, than a normal naval message. However when 
applicable, it is the most efficient way to route logistics traffic. The SAMS system 
should allow for transmission in either format as well as manual requisitioning. 

2. Requisitioning 

Ships and other naval units may submit requisitions for conventional 
antmunition in one of three formats as previously alluded to. A manual requisition. 
DD Form 134S, Figure 2.9 , may be completed and physically delivered or mailed to a 
shore weapons facility. The shore activity enters the requisition into the C.AIMS with 
their .ADP equipment. SPCC routes the requisition to the appropriate Inventory 
Manager (SPCC,N.AVAIR,NAVSEA,NMWEA,JCMPO). and an appropriate stock 
point is selected to deliver the material. 

.A message requisition may be prepared in DAAS format. Figure 2.10 , and 
electrically transmitted. A requisition line item on a DA.AS message is printed on one 
horizontal line or 66 characters, with no separations. .A DAAS message may also 
contain followup actions, modifications, cancellations and other logistics actions 
besides requisitions. The type of action is determined by the document identifier, 
column 1-3. The Routing Identifier (R I), colunm 4-6. is analyzed and the line item 
<;ent to its addressee. In this format the requisition is fully machine readable. 
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Manual Requisition Document. 
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Figure 2.10 DAAS .Message Requisition Format. 
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DAAS has restrictions however. There can be no narrative remark.*;, the 
classification must be UNCLASSIFIED, and the RT must be a continental United 
States (CONUS) activity connected to AUTODIN. Usage of DAAS by afloat units is 
somewhat limited by fleet commander instructions which require narrative remarks and 
pnmar>’ addressee other than DAAS. Dayton, OM on some ammunition items. 

The last requisition format is the normal narrative naval message. Figure 2.11 
. It should be noted that information and codes present on any of the three formats are 
almost identical. Fleet commander instructions require some minor format changes. 
The Pacific Fleet Conventional Ordnance Management Manual [Ref 4: p. 1-1-A-S] for 
example, requires that the quantity and NSN be spelled out on naval message 
requisitions to prevent confusion in the event of a garbled message. In any case, this 
format is not machine readable and must be entered into CALMS at a shore activity. It 
is more flexible however than a DAAS formatted message. Remarks may be included, 
it may be addressed to any activity, and it may contain classified information ( the 
remarks generally are the only classified information). 

The three formats are reasonably well described [Ref 3: Chapter 8]. The 
codes are rather cryptic and their full names are shown below. Explanations may be 
.^ound in .appendix B, the Data Dictionary. 



TABLE I 

MISCELLANEOUS REQUISITION CODES 



Code 


Full Name 


D/I(Doc. Ident. ) 

R/I 

M&S 

Serv 

Dem 

Sig 

Fund 

Dist 

Proj 

Pri 

RDD 

Adv 


Document Identifier 
Routing Identifier 
Media and Status Code 
Service Code 
Demand Code 
Signal Code 
Fund Code 
Distribution Code 
Project Code 
Priority Code 
Required Delivery Date 
Advice Code 
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Figure 2.11 Naval Meassage Requisition Formal. 
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3. Turn-in/Transfer 

Ships often have to turn-in ammunition that is excess, reclassified by NARs. 
or requiring periodic maintenance ashore. The DD Form 134S-1 is used for this 
purpose. Figure 2.12 . Somewhat fewer coded items are necessary on this form because 
the ship is physically delivering the material to another activity. Most commands also 
select another group of serial numbers for turn-ins, in order to differentiate them from 
requisitions. A separate log is maintained. The CALMS manual [Ref 3: p. 8-3-1], 
assists the user in completing the form. 

4. Receipt 

.Ammunition is also received on DD Form 1348-1. The document number on 
the receipt document corresponds to the receiving ship's requisition document number, 
of course the possibility of being sent material that was not ordered exits. The only 
new data items that have not been previously discussed are the unit price and the unit 
of issue, both of which are listed in the Stock List of Na\w Ammunition [Ref I2j. 

5. Discussion 

The requisition, turn-in/transfer, and receipt documents require some form of 
logs to be kept. .A Requisition Log may contain a history' of requisitions and receipts 
by document number (serial number). A Turn-in log would be similar. Retention of 
these documents provides a source of information for the future, instead of having to 
look up the information all over again. This is not necessarily a good practice as 
certain data elements may have changed in the interim. But this is just the kind of 
thing a busy sailor might do to save time, not recognizing the potential problems 
involved. Recall of the many different data items from publications can be time- 
consu.ming. 

C. AMMUNITION TRANSACTION REPORTING 

Transaction reporting is required for any action, event, or procedure that results 
in the receipt, issue, transfer, expenditure, loss, gain, reconfiguration or change in 
material condition of reportable material. [Ref 3: p. 8-4-3]. 

The format of Ammunition Transaction Reports (ATR's) has recently been changed to 
allow optical scanning of the data elements which are separated by from one to four 
slashes.",". .ATR's have multiple formats depending on the type of transaction, the 
MCC of the material (i.e., SLIT or non-SLIT), and the actual type of the material. 
This extreme variability has traditionally caused the greatest problem, resulting in a 
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Figure 2.12 



Manual Turn-in Document. 
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high error rate for these documents. Although the new format is more efficient in that 
it can be optically read and entered into the CAIMS by shore activities, it is now 
incomprehensible to the feet user. Therefore each ATR must be created in a 
painstaking step-by-step manner, minding the format and content of each data 
element. ATR's are transmitted as naval messages to SPCC, with information 
addressees and classification depending on the type of ordnance and the type of 
sending platform (i.e.. submarine, surface vessel ). Figure 2.13 illustrates one format of 
.\TR. The serial numbers run from 001 to 999 and then repeat, with a ship's most 
recent .ATR indicated in the current .ATR's reference line. This is to ensure that SPCC 
receives all ATR's from a ship without ommission. and in the correct sequence. Again, 
multiple transactions can be listed on one message as long as the common information 
in the header applies to all the transaction line items. Figure 2.14 attempts to illustrate 
the various ATR formats, the variability is evident. Each vessel keeps an ATR log to 
form the primary historv’ of the ship's ammunition transactions, from overhaul to 
overhaul, and to allow correction of any ATRs that were submitted with incorrect 
data. This log may consist of all the actual messages and a summary of each ATR with 
its elFect on the running total of each item involved. 

Properly submitted .ATRs are critical for the overall functioning of CAIMS. The 
old adage " garbage-in, garbage-out " aptly applies, and it is sincerely hoped, by all 
levels, that higher echelons are not making procurement and allocation decisions based 
on incorrect data. 

D. CO.MMENTS 

In addition to comments made throughout this chapter concerning data 
redundancy, multitudes of codes, and more than a few reference publications, mention 
should be made of the lack of any standardized record keeping procedures. 
Requisitions, turn-in documents, and ATRs must be submitted, and inventory' cards 
maintained, but no system or procedures exist for the maintenance of logs or records. 

It is generally accepted that some sort of auditable system must exist to resolve 
discrepancies and maintain accountability. The procedures that each individual ship 
creates may range from excellent to poor. Some ships may have even written ship's 
instructions for this purpose, detailing the manual methods to be used. .A software 
package, such as the proposed SAVIS, will have several benefits besides more accurate 
and timely ATRs. It will keep all logs and records for the user, it will standardize 
procedures without requiring the user to create new logs and binders, and finally it will 
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Figure 2.13 Ammunition Transaction Report (example). 
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Figure 2.14 Ammunition Transaction Report Formats. 
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all fit on a disk or diskettes. It might even save a few nervous breakdowns when new 
Weapons Officers report onboard to find no system in existence at all. 
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III. AN AUTOMATED SYSTEM DEVELOPEMENT 



The purpose of Chapter II was to give the reader a basic knowledge of the 
records and reports presently used onboard non-automated ships of the Xa %7 for 
conventional ammunition inventory control and accountability. Problems of data 
duplication, lack of standardized record keeping procedures, data inaccessibility, and 
late and inaccurate e.xternal reports as a result of these were discussed. This chapter 
shall develope a database management system (DB.MS) solution to illeviate those 
problems as well as reduce the administrative burden on ship's force personnel. 

A. METHODOLOGY 

It is now generally accepted that systems analysis and design must follow an 
orderly, logical process to arrive at a system that is reliable, maintainable, efficient, and 
manageable (i.e. within cost and time). The Shipboard .Ammunition Management 
System (S.AMS) deveiopement has followed such a process with certain modifications 
that reflect the new technologies of the DBMS and its easy to use programming 
language. 

Structured analysis and design evolved in the 1970's to bring a disciplined 
approach to computer system deveiopement. The I950's and I960's were characterized 
by haphazard analysis and design techniques and what .Vleilir Page-Jones referred to as 
the "Instant Karma" approach of computer system deveiopement [Ref 15: p. 27]. 
.Vlany excellent books now exist on the subject of structured techniques, 
[Refs. 15,16,17], so the treatment here will be brief and only as it relates to the S.A.MS 
deveiopement. Davis [Ref 17: p. 8] defines the steps involved in a structured 
deveiopement, or life cycle as: 

1. Problem Definition 

2. Feasibility Study 

3. .Analysis 

4. System Design 

5. Detailed Design 

6 Implementation 

7. .Maintenance 
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The relative weight that each step carries and the time spent in each area, of 
course depend on the project at hand. Most organizations use, or have used, some 
derivative of this basic life cycle in their system dcvelopement process. A reasonable 
approach is to study the available structured dcvelopement philosophies, modify these 
where adviseable to accomadate new technologies and tools, and apply the best 
composite plan. There have been worries among structured technique advocates that 
the new technologies, i.e. fourth generation languages, prototyping packages, and 
personal computers, will compnmise advances made in systems analysis and design. 
But, as Edward Vourdon, a prime advocate of the structured techniques, points out: 

The major philosophical concepts used to build reliable, maintainable 
information systems, which is what the structured techniques are all about, can 
continue to embrace new technologies without destroying the concepts 
themselves. [Ref. 16: p. 6J 

Chapters I and II went into some detail on the nature of the problem and 
defined the scope of the solution. A formal feasibility study was not conducted, 
however the major points of such a study were considered [Ref 17: p. 274]: 

1. Technical: Can the system be implemented with current technology? 

2. Economic; Do the benefits outweigh the costs? 

?. Operational or Organizational (Political); Can the system be implemented in 
this organization? 

Technical feasibility is well assured. Inventory control systems are not new. the 
data and reports required are well defined, and the DB.VIS products make the task less 
diiTicuIt. 

Economic feasibility, as usual, is hard to quantify. How much is a 10 per cent 
increase in system accuracy worth to Na\w planners responsible for ammunition 
procurement and allocation? Also, how much is the reduction in administrative burden, 
and the subsequent increase in operational readiness, worth? These are difficult 
questions to answer. In light of the relatively minor expense of the SAMS 
developement however, it only makes sense to pursue an alternative to the present 
manual system. If the project progresses beyond the research stage to fleet 
implementation, the increased costs would warrant a m.ore formalized cost benefit 
study. 
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Political feasibility should pose no problems. Weapons and operations personnel 
on most Navy ships are already heavy users of computers in their daily routines. Any 
labor saving device, which reduces records as v.'ell, would most likely be welcomied. 

B. .ANALYSIS 

The analysis phase of a project must fully determine what the system must do. 
How this is physically accomplished is the subject of the next section on design. For 
this author, the analysis phase began in 1983, unknowingly, with experience operating 
the manual system, which is largely unchanged today. However, under the pressure of 
multiple jobs, most users generally never acquire the big picture that is necessary to 
design an automated system. Normally the analyst will interview many people involved 
in dilTerent phases of the operation, plus review all the applicable documentation, to 
gain this big picture. This project required a slightly dilTerent approach. The author 
acted as an expert user 'analyst and based on experience and intense study, the system 
was designed and partially implemented. The pitfall here is that the expert user is too 
"expert" to really appreciate user difficulties. These difficulties would have to be 
resolved by a period of "normal" user interaction in the fleet following complete 
implementation. It will be shown that a DBMS makes such modifications, as may be 
necessary to suit the bulk of the users, much easier to perform. 

A complete knowledge of the existing system was the first major job in the 
SA.MS developement. Information, publications, instructions, reports, and forms were 
collected from all the commands and agencies involved in the flow of conventional 
antmunition to the lleet. The intent, policies, and procedures of the CAIMS program 
were studied to gain this big picture, even though many details did not directly affect 
the end user environment. There are several "layers" of instructions that deal with 
similar, or the same topics, and the semantic inconsistencies between these often 
necessitated phone call and extensive cross referencing to resolve. This overlapping of 
instructions is seen by this author as a definite problem. It can thwart a clear end user 
understanding of the system, since they have little time for phone calls or extensive 
research. 

The object of S.A.MS is to automate the end-user inventory and control 
procedures while remaining compatible with requirements of higher level Navy 
instructions. External report formats must be as described in Chapter II, however 
internal stock cards would not be used in an automated system naturally. This would 
require modifications in those instructions deleting the requirem*ents for those cards for 
the ships that are automated. 
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1. Data Flow Diagrams 

One of the major tools of structured analysis is the use of graphical 
representations to depict information flow. Data Flow Diagrams (DFDs) are a network 
representation of a system which is generally much easier to understand, at least by the 
end-user, than the functional specifications of the past. The DFD is an analysis tool, 
and as such, is logical m nature and does not depend on hardware, software, data 
structure, or file organization. logical representation is one that reflects a user's view 
of the system and it s processes. Several references [Refs. 15.17: p. 60.2811. similar 
descriptions of the constituent parts and developement of DFDs. Figure 3.1 shows the 
Fundamental System .Mode! or the Conte.xt Diagram for the SA.MS. This is the highest 
level of abstraction and shows the entire system as a single node. The user inputs data 
to the system or requests processing at the source square, the system node performs 
the necessary processing, and outputs data and, or reports at the sink square. This 
conte.xt diagram serves as a starting point but is not particularly useful or informative. 
Subsequent levels of refinement form a complete set of Data Flow Diagrams for the 
SA.MS and are included as .■\ppendix A. 




Level 0 



Figure 3.1 S.A.MS Context Diagram. 



Data Flow Diagrams do not show flow of control or sequence of execution of 
the processes. Also, the representation of files are purely logical and may be 
implemented quite differently in the final design. 
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2. Subsystem Functional Description 

Experience and research provided the logical divisions for the conventional 
ammunition management problem. Nine subfunctional areas were identified. 

1. User Access Validation 

2. General Information Documentation 

3. Inventor.' .Allowance .Ammunition Data 

4. Transaction Management 

5. Requisition .Management 

6. Turn-in Document .Management 

7. NARS .Vlanageinent 

S. System Management 

9. Generate Internal Reports 

This system breakdown seems obvious on the surface to anyone familiar with the 
manual system, as well it should be. The more closely an automated system follows the 
logical, or user's view, of the processes, the higher probability there is of the user 
feeling comfortable with the system. However, the system breakdown also considers the 
system goals and improvements desired in the automated system over the manual one. 
a. User Access I Validation 

The User Access, 'Validation function should ensure that only authorized 
users of the system may gain access. The SAMS is intended for use by Weapons 
Department personnel charged with the responsibility for ammunition, and as such, 
they should be the only people manipulating the system. Requests for .system data 
from superiors can quickly be accessed by these people. The system should be capable 
of controlling authorized user's priveledges within the system also. The S.A.MS only 
requires two basic levels of access. The lower level should allow access to the day-to- 
day processing options, two through seven and nine. The higher level will allow the 
S.A.MS administrator or manager to access all modules for system initialization, 
infrequent data changes, user changes, or to correct unforeseen system processing 
problems. This degree of power places great responsibility on the administrator and 
requires that he be fully knowledgeable of the system and the consequences of his 
actions. The risk in this approach is necessary however, because there will be no 
technical representative or outside help if the system developes a problem while at sea. 
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b. General Information! Documentation 

The second option provides general information and documentation that 
the user may find useful in getting acquainted with the system. This may include a 
system description, explanation of the options available, what the system does not do. 
hardware requirements, basic keyboard operaticns.etc.. .Also, this option should give 
the codes and de.hnitions that are frequently used by the S.A.MS and within the C.AI.MS 
system as a whole. data dictionary’ will not only explain the many acronyms but will 
increase the knowledge of the user and assist the manager in system management. 

Finally, a help program can be resident within this option and called from 
various places throughout the application programs. It is very difficult however, to give 
adequate help to a user with generic help messages about a particular question he may 
have. The author feels that giving more, rather than less information in the user 
interface is generally less frustrating than needing to frequently use a help program. 
Now, if the program was in constant use by a dedicated operator the extra verbage 
would become annoying, however that should not be the case here. The data entry to 
the S.AMS would probably slow down an operator who has all of the many codes 
memorized, but for those less gifted (the majority), the system will minimize the time 
referencing manuals. Also, the instructive goal of the system can be more easily 
accomplished in this manner. 

c. Inventory! Allowance! Ammunition Data 

This is basically a review option. The user would frequently want to review 
the current status of his onboard inventory, perhaps with a quick overall perspective in 
mind or a detailed review of a particular item. The SA.VIS inventory’ information 
should make the present record cards unnecessary. Since the change in an inventory 
level can only occur as the result of a transaction of one kind or another, the inventory 
is not manipulated directly, but is updated as a result of transaction processing. 

Allowance information can be conveniently stored in the system where 
training e.xpenditures can be updated and monitored. Again, any update occurs as a 
result of transaction processing. 

Ammunition data is that generic information about a particular item that 
does not change as a result of transactions and previously would have been looked up 
in one of several publications. See references 12 and 14 for examples. Any amount of 
information, about any kind of ammunition, could be loaded into the system, however 
to save disk space, only those items the particular ship would likely carry should be 
entered. The system manager can add or delete items as necessarvt 
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d. Transactions 

Transaction Management is the major processing function of the system. .A 
unit can receive items through a receipt, condition code change, or a few other 
infrequent occurances. It can reduce stock by an issue, expenditure, condition code 
change, or other reason. This subsystem should recognize the type of transaction, 
update inventories, create the information that will go on the ATR, and update other 
f.les when necessary. For example, a receipt transaction should update the requisition 
file if the receipt occured as a result of a requisition the ship submitted. An expenditure 
transaction should update the .Allowance File if that item had a training allowance. 

e. Requisitions 

Requisition Management involves the creation of requisition documents in 
the various allowable formats. The MILSTRIP system, dicussed earlier, is heavily code 
oriented, and this option should guide the user through the selection of the proper 
codes for the particular item at hand. This module should also store the information as 
a permanent record, eliminating the need for manual records. A user may edit these 
records during creation and prior to their being submitted, however the integrity of the 
data would be violated if he were allowed to do so afterward. Therefore, as with ATR's 
and Turn-in documents, there is a point where the data must be committed, and not 
changeable by the user. Any special cases could only be adjusted by the system 
manager. 

/. Turn-in Documents 

The Turn-in Document .Vlanagement function must create and store the 
turn-in record and print the DD Form 1348-1, the Single Line Item Release Receipt 
Document. The processes involved are very much like the requisition management 
function; one representing imminent issue and one representing imminent receipt. 
Later, when the transaction actually occurs, an issue transaction can be processed 
which updates the inventory. Naturally, the information already recorded by the Turn- 
in processing need not be collected again, rather the Turn-in file is linked to the 
Transaction file and the information transferred. 
g. NAR Messages 

Naval Ammunition Reclassification (NAR) Management serves to process 
these messages as they are received. .A stock check must be conducted to determine if 
the ship holds any of the ammunition lots specified in the message. If the check is 
negative, the only action required is to log the serial number of the NAR message. If 



42 



the stock check shows that action is required, then the proper reclassification 
transaction must be processed. The information pertinent to the NAR must also be 
saved for future reference and historical records. There should also be a link between a 
reclassification transaction and the NAR message that precipitated it. 

h. System Management 

The System .Management module will be extremely powerful, allowing the 
manager to globally edit all files and initialize the system. He will also be able to 
manage the security system, archive old records, recover the system when necessary' 
from backup files, and have access to the operating system and DB.VIS dot prompt. 
System documentation, of no real value to the normal user, will be available to the 
manager, to further his understanding of the system. 

/. Internal Reports 

Lastly, the Generate Internal Reports function will produce those reports 
that the typical users, and their supervisors, would find useful in management of their 
conventional ammunition program. Of course, the information would also be available 
on-line, but it is often useful to have hard-copies. Microcomputers will still not fit in 
one's back pocket! The SAMS should be flexible enough to allow' future report 
requirements to be incorporated without system redesign. The data flow diagram for 
this function describes several of the anticipated reports, however expansion is 
probable as new requirements come to light. User experience w'otild suggest other 
useful reports. 

3. System Data 

.As the name would suggest, a data flow diagram show's the data that 
interfaces the active processing areas of the system. The data is stored in files for later 
recall or processing. A convenient w'ay to aid the analysis of a system is to identify the 
data that is require at the "sink" and work backw'ards through the system to the source 
of the data. The S.A.VIS has certain data elements that it must be able to produce to 
construct .ATRs, requisitions, and turn-in documents. Also, it must record the 
inventory data to replace the manual stock cards. This data then forms the minimum 
set for the system. Table 2 identifies the data that is included in these output 
documents and the stock cards. 

These data elements thus form the initial inputs to a Data Element Dictionary 
(DED). .A DED is basically a collection of data about data. The idea is to provide 
information on the definition, structure, and use of each data element in the system 
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TABLE 2 

SAMS OUTPUT DOCUMENT DATA ELEMENTS 



Transaction Repor 



From: 

, Name 

Info: 

Info Addresses 
Date of last ATR/ 

or last ATR DTG 
I Own ship UIC 
ATR Serial 

' Activity Class. Code 
, Julian Date 
I NUN 

Beginning Balance 
Quantity 

User ID/Source ID Code 



Turn-in Document 



Data Elements 



Document Number: 

Serv. Desig. Code 
UIC 

Julian Date 
Serial 

Ending Balance 
Lot Number 

Component Serial Number(s) 
Maintenance Due Date 
Type of Maintenance Due Code 
Old Condition Code 
New Condition Code 
Transaction Code 



Elements 



Stock Number: 

! ESC 

NUN 

Unit-of-i ssue 
I Quantity 
I Document Number: 

Serv. Desig. Code 
UIC 

I Julian Date 

Serial 

Distribution Code: 

Monitoring Activity 
Cognizance Symbol 
Project Code 
I Unit Price 
I Shipped from: 

I Serv. Desig. Code 

I UIC 

Name 

Hull Number 



Ship to: 

Serv. Desig. Code 

UIC 

Name 

Location/Hull Number 
Total Price 
Security Risk Code 
Material Condition Code 
DOT Class. Code 
C. G. Hazard Code 
Lot Number 

Component Serial Number(s) 
NALC 

Noun Name 
NAR Number: 

NAR Serial 
NAR Year 

Date Shipped or turned in 
Freight class. Nomenclature 
Type of Container 
No. of Containers 



I 



44 



TABLE 2 

SAMS OUTPUT DOCUMENT DATA ELEMENTS (CONT'D.) 



' Requisition Data 

Rsquisitior.ee; 

, ”Serv. Desig. Code 

, UIC 

I N ame 

I Location/ 

I Hull Number 

I Requi sitioner: 

Serv. Desig. Code 

UIC 

Name 

Hull Number 
Document Identifier 
! Routing Identifier 
Media and Scatus Code 
Srock Number: 

?SC 

I Ml IN 

I Unit-of-issue 
Quantity 



Inventory Record 

Transaction Jul. Date 
Docu.ment Number: 

Serv. Desig. Code 
UIC 

Julian Date 
' Serial 

Transaction Code 
I Quantity 
I Condition Code 
! ATR Serial 

Unexp. Trng. Allowance 
I Allowance 

I 90% of Shipfill Allow. 

] Annual Trng. Allowance 



Elements 

Document Number: 

Serv. Desig. Code 
UIC 

Julian Date 
Serial 
Demand Code 
Supplemental Address: 
Serv. Desig. Code 
UIC 

Signal Code 
Fund Code 
Distribution Code: 

Monitoring Activity 
Cognizance Symbol 
Project Code 
Priority Code 
Required Delivery Date 
Advice Code 
Info. Addresses 



Data Elements 
NALC 

Cognizance Symbol 
NliN 

Material Control Code 
Activity Class. Code 
DOT Class. Code 
Net Explosive V^eight 
Stowage Location 
C. G. Hazard Code 
Consignor/Consignee UIC 
Lot Nu.mber 

Component Serial No. (s) 
Maintenance Due Date 



I 



i 



[Ref. 17: p. 296]. Table 3 lists the format of the information that will be stored in the 
DED for each data element. By exactly defining the meaning and structure of the data 
elements, standardization among the application programs is facilitated. .Also, as will 
be discussed, relationships between data can be utilized to greatly increase the amount 
of useful information the system can produce. This can only be accomplished if 
consistent data definitions are observed. The DED for the SAMS will be an on-line 
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facility for user reference and may also be printed for hard copy documentation. 
•Appendix B is the SA.MS Data Element Dictionar>’. 

C. DATA ORGANIZATION 

1. File Processing 

A final consideration, and one of primarx’ importance, is the manner in which 
the system's data is stored and represented. Traditionally, file processing systems 
organize all of the data for a particular specialized application into a single file and the 
program operates on that file to produce the output. In this manner, the file is really 
just a storage medium for potentially ver\‘ dissimilar data. No data organization is 
implied other than sequencing. Other specialized application programs would operate 
on files that contain all of the data necessary for that application. In terms of the 
S.AMS. such a system might be structured as in Figure 3.2 . 

There are some immediate problems with this method of file and data organization for 
an ammunition management system. First, since each file contains all of the data 
needed for it's program, there is much redundant data in the system. This of course 
requires much redundant data entr\’ which the operator resents because he logically 
questions the necessity for doing it. For example, each of the files in Figure 3.2 , and 
their associated program, require the name of the ship producing the documents, and 
thus the files must contain that data. This type of redundancy has traditionally been 
accepted because the programs that would be required to share data among files were 
complex. Unless all the application programs and files are constructed with 
compatibility in mind, a conversion process between diflerent record formats might be 
necessarx’. .A one-of-a-kind request necessitating shared data would have to be vitally 
important to merit such effort. 

This lack of integration capability limits the information that can be obtained 
from the data. However, the redundancy of data also presents problems other than the 
multiple data entry required. It wastes storage space in the files, which is important 
when considering a microcomputer application. The larger files also cause slower 
processing times for the system as a whole. Finally, when data elements change, the 
difierent programs must all be updated or inconsistencies will result. 

2. Database Processing 

Database processing is quickly gaining ground on file processing in most ADP 
applications and has several major advantages over file processing techniques. First 
and foremost. Data Base Management Systems (DBMS) allow the sharing of data 
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T.ABLE 3 1 

1 

DATA ELEMENT DICTIONARY FORMAT 


ongtitle: 


The long title of the data element. 
It may contain up to 30 characters. 


Name: 


A short hand version of the long title 
to be used in programming and is compat- 
ible with the DBMS variable representation 
and length for record and field names. 

( 10 characters for field names and 8 

characters for record names. ) 


DEM: 


(Data Element Number) For those data ' 

elements that are cataloged in the 
Standard Data Element Dictionary! SDED)_, 
a DEN is assigned. The DEN consists of 
an alphanumeric character followed by 
three or four numerics. The DEN acts as 
a means for controlling data elements and 
as a short hand name. 


Picture: 


The data type of the element, i.e. 
character , numeric , logical, etc., and 
the width of the field. 


Desc. : 


The narrative description explains 
what data or information the element 
represents. 


Refs. : 


Publications and other documentation 
that give additional information about 
the data element. 


Codes: 


If the data element has codes associated 
with it, the reference that lists all 
those codes and their meanings is given. 
(Most codes are given in the General 
information option 1 . ) 


Used in: 


All relations in which the data element 
appears. (SAMS Relations) 
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etc. 


etc. 




Figure 3.2 


File Processing System for S.AMS. 



between files quickly and easily. This is accomplished by the DBMS program itself, 
which is usually quite complex, but fotunately requires the user to know nothing about 
it's intricacy. Thus the system files are established under DBMS control in a 
compatible format. Application programs only communicate with the DBMS, as far as 
data retrieval is concerned, and it "fetches" the desired data by it's own means. Sharing 
data means that a reduction in redundant data is now' possible through intelligent file 
design. In contrast to Figure 3.2, Figure 3.3 is a representation of how the SAMS 
might be constructed using database technology. 

•A. DB.MS also creates program'data independence since the programs do not 
need to know anything about the data structure of the files. We can add application 
programs that use any of the files and this gives much flexibility in system design. 
Fields can even be added or deleted from the files without any efiect on the programs 
that do not explicitly use the affected data. 

There are some disadvantages to database systems, however for medium-to- 
small applications, with much interaction, they are very insignificant [Ref IS: p. 6]. 

The SAMS will therefore use a modern commercial database package. dBase 
III Plus, by .Ashton-Tate of Torrence, California. This is a moderately priced package 
for use on microcomputers and has gained much popularity. DBase III Plus is a 
relational database which simply means that data is represented in the form of tables, 
or relations. Readers interested in a full discussion of relational database theoiy should 
refer to Date [Ref 19], Ullman [Ref 20], Kroenke [Ref 18], and Brodie [Ref 21]. 
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Figure 3.3 Database System for SAMS. 



It was previously mentioned that a reduction in redundant data was possible 
through intelligent file, or relation design. Good design consists of properly matching 
the data elements, or attributes, of a relation so as to prevent data integrity problems. 
Wetherbe and Dickson [Ref. 22: p. 213] describe the common integrity problems as: 

1. Difficulty in accurately identifying, locating, or updating all records given a 
specific set of attributes. 

2. Needlessly repeating fields in records, therefore requiring redundant storage and 
updates. 

3. Inconsistencies among data. 

4. No records within which to store certain fields. 

The process of normalization is a set of rules or guidelines which help a 
database designer build relations that minimize update anomolies and data 
inconsistencies. For larger systems with a high transaction rate, strict compliance with 
all of the normalization rules can lead to conflict with retrieval performance because 
normalization generally results in more relations. This then requires more effort to 
retrieve all the necessary data. The SAMS however, will be a relatively small system 
with a low' transaction rate, and therefore the design should strive for maximum 
reasonable normalization. Excellent descriptions and examples of the normalization 
rules are given in Kroenke [Ref. 18: p. 2S6] and Kent [Ref 23]. 

There are seven nonnal forms identified, and in consideration of the type of 
data involved in the SAMS, it may be difficult to apply higher than the Boyce-Codd 
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normal form (BCNF; in most cases. Briefly, the guidelines, or rules up to this point 
are; 

1. .A.11 records in a relation must contain the same number of fields and none must 
repeat. This is basically the definition of a relation in relational database theory. 

2. The second normal form requires that all non-key attributes are dependent on 
the key. .A key is one or more attributes that determine a record. 

3. Third normal form is satisfied when no non-key attribute provides a fact about 
another non-key attribute. 

4. Boyce-Codd normal form requires that every attribute that provides a fact 
about another attribute (determinant), must be capable of being a key for the 
relation (i.e. a candidate key). 

Thus, analysis concludes with the generation of DFDs, the functional 
descriptions, identification of the data and it's structure, and consideration of the 
normalization policies for the database relations. 
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IV. SAMS DESIGN 



The design of the database relations for the S.AMS is a critical juncture in the 
de\ elopement process. For the reasons discussed in the previous chapter, thoughtful 
design of these relations will ensure the fle.xibility and integrity of the system. 

Relation design is not an easy task, even for a relatively small system like SAMS 
With only a hundred or so data elements. A starting point is to logically group data 
elements as was done for the e.xternal reports and stock records in Table 2 . We must 
also then consider the data elements that deal with generic ammunition information, 
allowance lists, NAR messages, addresses of other Na\w units, and constant data 
referring to a particular ship {static data). If we assem.ble these lists independently of 
each other, there is much data duplication which must be minimized for the 
normalization we require. 

To store data elements in one relation, yet link them to other relations, there 
must be co.mmon attributes between the two relations. However, these attributes must 
be unique so that the DB.VIS can locate the correct record. This normally requires that 
the relationship be established to a key attribute. DBase 111 Plus requires that the 
attribute that is being searched for be an "index" of the relation. An index is a file that 
is created for an associated database relation which contains a particular attribute in 
alphabetical, or alphanumeric order and its associated record number in the database. 
This allows the DBMS to quickly search for a particular value of an attribute in the 
index file and obtain the corresponding record number in the database file. When 
records are added or deleted from a relation, only the indexes are reorganized which 
could save considerable time in a large database. .Vloreover, many indexes can exist, on 
different attributes, for the same relation. 

With these considerations in mind, the SAMS data elements are separated into 
appropriate relations and indexed as deemed appropriate to accomplish the file 
relationships desired. The relation structures will be fully described with regard to 
normalization in the next section. 

.Although compatibility in data elements or software is not required of the 
S.A.MS. as it is a stand alone system, it was desired that data elements used in the 
CAI.VIS be used by SA.VIS where possible. This resemblence would minimize any 



difTiculties in user understanding when referring to supply system or CAIMS 
publications. Also, since CAIMS already has a Data Element Dictionary (SDED), it is 
a question of not "reinventing the wheel". If data elements in this dictionary were 
directly applicable to the SAMS, they were used. Minor modifications in data element 
name or picture were necessary in some cases (COBOL vs. dBase III Plus ), but the 
meanings were close enough to assign the CAIMS Data Element Number (DEN) to 
the SA.MS element. 

Table 4 lists the conventions used in selecting the SA.MS database and index 
names. It is easy to see that some sort of pattern is necessary in selecting file names, 
their number quickly grows beyond human memory. Table 5 conveniently lists the 
database files and their associated index and format files. A format file is constructed 
by the DBMS, with user interaction, to create custom data entry screens. Even this 
relatively small system is composed of over fifty programs and fifty files, therefore 
program and file directories are also needed. A complete program directory is included 
as Appendix C. 

A. SAMS PHYSICAL RELATION DESCRIPTION 

Table 6 lists the physical structure for all of the SAMS database files. It would be 
helpful to the reader to refer to this table throughout this discussion. 

1. Transaction File (ATR File) 

This file contains the data elements that relate specifically to a particular 
transaction. The key in this file is the ATR serial number (ATRSERIAL). To 
normalize to the Boyce-Codd Normal Form (BCN’F). every determinant must be a 
candidate key, and the only key here is the ATR serial number. Every other data 
element should furnish a fact about the key, and only the key. and this is satisfied with 
one exception mentioned later. 

As mentioned in Chapter II, ATR numbers run from 001 to 999 and then 
repeat. It would take quite a few years for the typical ship to go through 999 numbers. 
Repeating key elements can not be permitted so if there was a chance of this, the old 
records would be archived. Old instructions required that ships restart their ATR 
numbers when "chopping" (Change of Operational Command) to another fleet. If this 
situation existed on a ship that S.A.MS was to be installed, the old fleet numbering 
seqeunce should not be included in the initialization to prevent repeating key field 
values. 



TABLE 4 

SAMS FILE NAMING CONVENTIONS 



A. Database Files ( . dbf ) 

1. First two letters - system prefix- Ammunition 
Management "AM" 

2. Third-Eighth letter - description of file 
contents 



3. Index Files ( . ndx) 

1. First two letters - system prefix - Ammunition 
Management "AM" 

2. Third letter - .dbf file description 

a. Requisition - "R" 

b. Ammunition Data - "A" 

c. Transaction - "T" 

d. Inventory - "I" 

e. Turn-in - "U" 

f. Allowances - "W" 

g. MAR Action - "N" 

h. NAR Serial - "E" 

i. Static Data - none 

j. Address - "D" 

3. Fourth-Eighth letter - index file description 



C. Format Files ( . fmt) 

1. First-Third letter - "ADD" 

2. Fourth-Eighth letter - description of .dbf file 
contents 
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TABLE 4 

SAMS FILE NAMING CONVENTIONS (CONT'D.) 



D. Exceptions 

1. DESYSTEM. db - User's File (encrypted) 

2. CONTFILE. dbf - Contains File - Programs <-> . dbf 

' files 

I 

3. DATAELEM. dbf - Data Element File 

i I 

j 4. DICFILES. dbf - Files Directory | 

j 5. PROOF IDE. dbf - Programs File 

I 

I 

The ATR Status is a local SAMS data element which serves to indicate the 
condition of a particular record. A transaction can be incomplete, ready for 
submission, or submitted. An "incomplete transaction" is one in which the user has not 
completed entering the necessary data or he is not ready to say the data is correct. This 
is strictly a user assigned status and no inventory update takes place based on an 
incomplete or blank entry. When the user is satisfied that the data is correct, he 
changes the status to "ready for submission", and inventory update takes place. At this 
point he may print the ATR for submission to the Radio Room or Communications 
Center, however he may not edit or delete the record. When the message is routed back 
from the communications personnel, verifying broadcast, the status can be changed to 
"submitted", and the message Date Time Group (DTG) entered. The DTG may be 
used on subsequent ATRs and thus must be retained. 

The National-Item-Identification-Number (NUN) uniquely identifies a type of 
ammunition and can therefore be the link to the Ammunition Data file to obtain the 
Type of .Vlaintenance Due Code (TMDC). The T.MDC will be required on ATRs that 
involve Serial Lot Item Tracking (SLIT) material. 

To uniquely identify an ammunition item that is or was physically in the ship's 
inventory, not only the NUN, but the Condition Code (CC), Activity Classification 
Code (ACC), Lot Number, and Component Serial Numbers (if applicable), are 
required. .Multiple items with serial numbers can be included on one ATR, so up to ten 
serial numbers may be included in this record. Unfortunately, in one regard, variable 
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DB File ( 


. dbf ) 


T.ABLE 5 

SA.MS FILE GROUPS 

Index File (,ndx) Format Files (., 


AI'IREOUIS 




AMRSERUP 

AMRSERDW 

AMRREQDD 


ADDREQUI 


AmOD.^TA 




AMANALC 

AMACOGSY 

AMAMCOMC 

AMANIIN 


ADDAMMO 

AMMODATA. dbt 
(memo field) 


AMTRANS 




AMTSERUP 
AMTSERDW 
AMTTRCD 
AMTNI IN 


ADDTRANS 


AMINVSM 




AMINIIN 
AMICONCD 
AM I ACC L 


ADDINVEN 


AKTURNIN 




AMUSERUP 

AMUSERDW 

AMUNIIN 


ADDTURM 


AMALLOW 




AM^'TNALC 

AMWALTP 


ADDALLOW 


AflNARACT 




AMNNIIN 

AMNSERUP 

AMNSERDW 


ADDNARAC 


AMNARSER 




AMENARSR 


ADDNARSE 


AMSTDATA 




none 


ADDSDATA 


AKDADDR 




AMDUIC 

AI»1DACTNM 


ADDADDRE 


D5SYSTEM. 


db 


none 


none 


CONTFILE 




CONTNAME 


none 


DATAELEM 




DATANAME 

DATAELSR 


DATAELDIC 


DICFILES 




DICFILTP 


none 


RROGFILE 




PROGNAME 


none 



I 



record lengths are not defined in a relational data base system, so some storage space 
will be wasted because most transactions do not involve items with serial numbers. 
Only rarely would a transaction involve more than ten serial numbers. In this case, a 
second transaction report could be prepared. 
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The ATR Julian Date (ATRJULDAT) is the three-digit julian day of the year 
that the ATR is prepared and appears in the header line of the message. It will not 
necessarily be the same as the message DTG. 

The beginning and ending balance must be maintained in the Transaction file 
because the Inventory file is dynanric in nature having the "instantaneous" stock levels. 
Thus the Transaction file is the historical record of stock levels. 

Quantity seems an obvious data element in the ATR. however if the 
transaction is a receipt or issue, the document number of the associated receipt or turn- 
in document is also included. This case would violate the Third normal form because 
quantity is part of these documents. However, Quantity must be included because 
expenditure transactions have no corresponding document. 

The User Source Identification Code (IDCODE) is a similar situation. For 
receipts and issues the IDCODE would be the "ship to" or "received from" on the 
shipping document, however in other cases it can take on other values.Thus it must be 
included as part of the record. 

Finally, any narrative message (ATRREM.ARKS) must be saved and this is 
naturally the only place to do that. 

The preceeding description of the Transaction file and it's structure may have 
seemed rather tedious, however the reader should take heart that commonalities in the 
other files will not be repeated. 

2. Requisition File 

Serial number and julian date uniquely identify the requisition, while the other 
two components of a requisition document number are accessed from the Static Data 
file. The NUN again uniquely identifies the item that is being ordered. 

The requisitionee and supplemental address ETC and service codes are 
included in the requisition file. Ninety per cent of the time, an activity's ETC will 
determine it's service designator code, however if that activity is a ship and it changes 
fleets, then it's service designator code will change. The supplemental address is 
normally the activity at which the material will be received, or loadout activity. 

Requisition Status (REQLTSSTAT) serves a similar purpose to that in the 
.ATR file except that it must also be able to represent partially filled and cancelled 
requisitions. 

The remaining data elements are multi-valued codes which are all independent 
and describe the circumstances of the requisition, urgency of need, required delivery 
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date. etc.. See Appendix B. the Data Element Dictionarx', for a complete description of 
these items. This file also satisfies the Boyce-Codd Normal Form. 

3. Turn-in File 

The turn-in file may seem to be a redundant file in itself because it will 
eventually represent a turn-in transaction (issue transaction). However, two 
considerations help to clarify the need for the file. First, a turn-in document may be 
prepared well ahead of the actual transaction date and the timing of the inventory 
update would become a problem. Certainly the inventory should not be updated until 
the physical stock levels change. Secondly, a turn-in document requires three or four 
data items that are not needed on a transaction report and thus the ATR file would be 
made needlessly larger just to accomadate these items. 

The turn-in file record must be able to uniquely identify an item of inventory, 
just as the ATR file must. Therefore the same five data elements; NUN, ACC, CC, lot 
number, and serial number(s), must be included to accomplish this. 

The ATR serial number is provided to link the record to the transaction 
record in the ATR file. This data would be automatically appended to the record when 
the transaction document was prepared. 

Finally, a link to the N'AR Action file is necessary if the turn-in is in response 
to a NAR message. The NAR Serial member and the NAR Year accomplish this. 

4. Ammunition Data 

This file contains data elements that provide facts about specific items (types) 
of ammunition. The unique element is of course NUN. This file essentially replaces the 
need to reference two or three large publications and is accessed many times in the 
application programs. The Data Element Dictionary. Appendix B, contains complete 
explanations of these independent descriptors. 

One "confusion factor" still remains however. Although NT IN reporting, vice 
N.ALC reporting, is logical and consistent with good inventory^ control, NALC is still 
used as an identifier in NAR messages, allowance lists, and other documents. For 
years. N.ALC has been the defacto unique identifier of ammunition items, and until all 
organizations begin using NUN as such, the .Ammunition Data file will serve as the 
N.AR-to-NTIN converter in application programs. 

It is questionable if the NALC in this relation could be considered a candidate 
key. Many of the data elements realistically do provide a fact about the NALC, a non- 
key .field, so the Third Normal Form would be violated. This seems unavoidable in this 
case however. 
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5 . Inventon' File 

This flic is suprisingly simple. The five identifiers of an individual item are 
there along with the MDD which will be associated with serial number controlled 
items. If the item is serial number or lot serial number controlled (MCC "C" or MCC 
"E"). the quantity for the record will be one. Items that are only lot controlled or have 
no MCC will have a quantity that reflects all the items in the lot. This relation has 
such a large key (five data elements), that there are only two others that are not 
included, quantity and storage location. Boyce-Codd Normal Form is easy to attain in 
this case. 

6. NAR Action File 

This file contains reclassification data from a NAR message that affects 
inventory held on board. Only those N;\Rs that are applicable are entered here. The 
NAR Serial File records all NAR messages received so that any missed messages can 
be noted. 

Naval Ammunition Reclassification messages identify affected ammunition by 
NALC, lot number, and sometimes serial number. Since lot numbers are not 
necessarily unique, and a NALC may contain several NTINs, we must first determine 
the NTINs associated with a particular NALC. The inventory can then be searched for 
those NTINs, which are a key element of the Inventory file as well as an index. Upon 
locating an applicable NT IN, the lot number is compared with that contained in the 
N.AR message. This procedure would be much simplified if NAR messages used NTIN 
as the identifier. 

The NAR Action File also contains the ATR Serial Number which took the 
action the NAR called for. This would be automatically appended when a 
reclassification ATR vvas processed. 

Finally, this file contains a character field to record the reason for 
reclassification, which is normally included in the message itself. Also a field, 
TAG LABEL, to record the label or tag that must be attached to the actual 
ammunition to explain it's status. This label would be a statement like, "For Training 
Use Only", or "For Emergency Combat Use Only". 
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NAR Serial File 



This file's purpose is to provide a convenient location to record all the NAR 
messages received, whether applicable or not. This method allows the NAR Action File 
to be much smaller, since non-applicable NARs are excluded. Thus we minimize the 
size of a relation with nineteen fields by creating one with only three. This file is in 
Fifth Normal Form, which means that it is in BCNF and it contains no transitive 
dependencies (fourth), and it can not be subdivided in any way. 

S. Allowances File 

This file contains the authorized types of ammunition and quantities that a 
ship may carry. Allowance Lists, promulgated by the Naval Sea Systems Coinmand 
(N-AVSE.A). again use the N.ALC as an ammunition identifier [Ref 3: Chapter ^]. 
Remembering that the various N’llNs within a N.ALC group are functionally 
equivalent, it is clear why N'.AVSEA publishes the lists in this manner. A ship may 
carry any N'lIN' item within the N.ALC group to satisfy the Allowance List 
requirements. 

The inclusion of the Activity Classification Code (ACC) in the Allowance file 
allows ammunition for other end uses to be shown in this file rather than creating a 
dilFerent file for each .ACC material carried onboard. 

Finally, this file contains a computed quantity, USED FY, which will be 
automatically updated during expenditure ATR processing to show the quantity of 
ammunition, which has a training allowance, that has been used in the fiscal year. The 
system manager will need to reinitialize this quantity each year. Performing the 
computation at this time and storing the value is a departure from strict normalization, 
however it is far more efficient than doing all of the calculations just prior to printing a 
training expenditure report. 

9. Address File 

The Address file contains pertinent data about other supply activities and 
commands with which a ship may conduct ammunition business. The L'lC and Activity 
Name (ACTIVNA.ME) are both candidate keys, however LTC is less easily confused 
than two similar names and it is also only five characters. This makes it better as an 
index, decreasing search time. There are transitive dependencies in this file; Activity 
Name and Location can determine Service Designator Code, however Boyce-Codd 
Normal Form is still attained. 
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10. Static Data File 

This file is unique in that it only contains one record, namely data about the 
ship that the SA.MS is installed in. It furnishes information to application programs 
that need the ship's name, hull number, etc. to print documents and reports. The Fund 
Code is needed on requisitions and the .Monitoring Activity (.MONIT.ACTIV) is 
combined with the Cognizance Symbol to form the Distribution Code, used on several 
documents. 

The remaining database files are for system documentation and will not affect 
the operational performance of the system. 

B. S.A.MS STRUCTURE CHARTS 

The last step in the design stage is to determine how the system will be 
partitioned into modules, or programs. These programs will operate on the database 
relations, via the DBMS, and interactively with the user to perform their function. 
Unlike a Data Flow Diagram (DFD), the structure chart presents system hierarchy, 
control, and communication. .Appendix D presents the SAMS structure charts. 

Structured design has several measures with which to gauge the quality of a 
system's structure chart. The first is coupling, which is the degree of independence 
between modules, and the objective is to minimize this. The second is cohesion, wtuch 
evaluates how closely the activities within a module relate to one another. A module 
should be considered a "block box", in that it performs it's designated function with the 
surrounding modules knowing little or nothing about it's internal code. [Ref 15: p. 
101,117] 

A database management system tends to make structured module design an 
easier process than in the past. The problems of data storage are removed from the 
application programs and handled by the DBMS, thus traditional input, output 
modules are not necessary. This fact allows programs to flow from one logical process 
to another without the traditional housekeeping chores. Previously, structured design 
techniques responded to this by making modules very' small with single cohesive 
functions. .A DBMS with a good programming language can produce programs that 
remain understandable and cohesive while allowing a chain of logical thoughts to be 
contained in one program. 

The SAMS is menu-drive when the selections are unambiguous, and almost 
conversational when the selections require a more detailed knowledge. Referring to the 
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TABLE 6 

SAMS PHYSICAL FILE STRUCTURES 



Relation: Transactions 

DBMS Name: AMTRANS. dbf key (ATRSERIAL) 



riel 


d Field Name 


Type 


Width Dec. 


DEN 


- 


^ ATRSERIAL 


Mum 


3 


0 


C089 


2 . 


ATRSTATUS 


Char( A) 


1 






3. 


Ml IN 


Char 


9 




D046D 




.^CTCLCODE 


Char( A) 


1 




E303 


5. 


CONDCCDE 


Char( A) 


1 




C003E 


6. 


TRANSCODE 


Char( A) 


1 




D219 




ATRJULDAT 


Mum 


3 


0 


K002B 


8. 


LOTNUTIBER 


Char 


16 




C301 


?o/ 


OSERNUM/ 


Char 


16 




D330 


18. 


9SERNUM 


Char 


16 




D330 


19. 


MDD 


Char 


3 




C02 6 


20. 


3EG3AL.ANCE 


Char 


5 






21. 


EMD3ALANCE 


Char 


5 






22. 


OAUNTITY 


Num 


5 


0 




23. 


DCCSVCCOD 


Char( A) 


1 




K048 


24. 


DOCUIC 


char 


5 




A002 


25. 


DOCJULDAT 


Num 


4 


0 


K002C 


26. 


DOCSERNUM 


Num 


a. 


0 


K002B 


27. 


IDCCDE 


Char 


5 




I200/I602B 


28. 


MESSAGEDTG 


Char 


14 




C076 


29. 


ATRREMARKS 


Memo 


10 








Index Files: 


Field 




Name 








1 




AMTSERUP 


( increasing 






1 




AMTSERDW 


( decreasing 






3 




AMTNI IN 








6 




AMTTRCD 




Rela 


tion: Requisitions 








DBMS 


Name: AMREQUIS.dbf 


key( SERIAL, 


JULIANDATE) 


Field Field Name 


Type 


Width Dec 


DEM 



1. 


NUN 


Char 


9 




D046D 


2. 


QUANTITY 


Char 


5 






3. 


* SERIAL 


Num 


4 


0 


K002C 


d. 


* JULIANDATE 


Char 


4 




K002B 


s. 


PROJCODE 


Char 


3 




K024 


6. 


SSNDTOSERC 


Char 


1 




K048 


7. 


SENDTOUIC 


Char 


5 




A002 


8 . 


DOC I DENT IF 


Char 


3 




KOOl 


Q 


MEDIASTAT 


Char 


1 




K082 


10. 


DEMANDCODE 


Char( A) 


1 




K020 


11. 


SUPADDSERC 


Char 


1 




K048 


12. 


SUPADDUIC 


Char 


5 




A002 


13. 


SIGNALCODE 


Char( A) 


1 




K021 


14. 


PRIORITYCD 


Char 


2 




K025 


15. 


REQDELDATE 


Char 


3 




KC18 


16. 


ADVICECODE 


Char 


2 




K026 


17. 


REQUISSTAT 


Char( A) 


1 








Index Files; 


Field 




Name 








3 




AMRSERUP 


( increasing! 






3 




AMRSERDW 


( decreasing) 






15 




AMRREQDD 
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TABLE 6 

SAMS PHYSICAL FILE STRUCTURES (CONT'D.) 



Relation: Turn-in 

D3MS Name: AMTURNIN. dbf key ( SERIAL, JUL I ANDATE ) 



Field 


Field Name 


Type 


Width Dec 


DEN 


1 X 


SERIAL 


Mum 


4 0 


K002C 


2. 


NUN 


Char 


9 


D046D 


3. 


ACTCLCODE 


Char( A) 


1 


E303 


4. 


CONDCODE 


Char( A) 


1 


C003E 


5. 


LOTNUMBER 


Char 


16 


C301 


6./ 


CSERMUM/ 


Char 


16 


D330 


15. 


9SERNUM 


Char 


16 


D330 


16. 


QUANTITY 


Num 


5 0 




17. * 


JUL I ANDATE 


Char 


4 


K002B 


18. 


SKIPTOUIC 


Char 


5 


A002 


19. 


ATRSERIAL 


Num 


3 0 


C089 


20. 


NARSERIAL 


Num 


3 0 


C084 


21. 


RROJCODE 


Char 


3 


K024 


22. 


NARYEAR 


Num 


2 0 


C083 


23. 


TURNINST.AT 


Char( A) 


1 




Index Files: 


Field 

1 

1 

2 


Name 

AMUSERUP 

AMUSERDW 

AMUNIIN 


( increasing) 
( decreasing) 



Relation: Ammunition Data 

DBMS Name: AMMODATA. dbf key(NIIN) 

Field Field Name Type Width Dec DEN 



1. 


* NUN 


Char 


9 


D046D 


2. 


MALC 


Char 


4 


C003C 


3. 


FEDSUPCLAS 


Num 


4 0 


C042 


4. 


SHORTTITLE 


Char 


20 




5. 


COGSYMBOL 


Char 


2 


C003 


6. 


UMITOFISSU 


Char 


2 


C005 


7. 


UNITPRICE 


Num 


10 0 


B053 


8. 


MATLCONCOD 


Char 


1 


C003A 


9. 


DOTCLASCOD 


Char 


2 


P255 


10. 


HAZARDMTCD 


Char 


4 


D196 


11. 


NETEXPWT 


Char 


10 


C304E 


12. 


SECRISKCOD 


Char 


1 


C017 


13. 


LOMGTITLE 


Memo 


10 




14. 


TMDC 


Char( A) 


1 


COlO 


15. 


FRECLASNM 


Char 


32 






Index Files: 


Field 


Name 








1 


AMANIIN 








2 


AMANALC 








5 


AMACOGSY 








8 


AMAMCONC 





TABLE 6 

SAMS PHYSICAL FILE STRUCTURES (CONT'D.) 

i Relation: Inventory kev( NI IN, LOTNUMBER, 

' DBMS Name: AMINVEN. dbf SERNUMBER, CONDCODE , ACTCLCODE ) 



1 Field 
1 


Field Name 


Tyve 


Width Dec 


DEN 


1 . * 


NUN 


Char 


9 


D046D 


* 2. ^ 


LOTNUMBER 


Char 


16 


C301 


! 3 . * 


SERNUMBER 


Char 


16 


D330 




MDD 


Char 


3 


C026 


5. * 


CCNDCODE 


Char( A) 


T 


C003E 


6. ^ 


ACTCLCODE 


Char( A) 


i 


E303 




QUANTITY 


Num 


5 




1 8. 


STORAGELC 


Char 


30 




Index Files: 


Field 


Name 




1 




1 


AMINIIN 




1 




6 


AMICONCD 




i 




7 


AMIACCL 




Relati 


on: NAR Action 






1 DBMS Name: AMNARACT. dbf 


key( NARSERIAL, 


NARYEAR) 


Field 

1 


Field Name 


Type 


Width Dec 


DEM 


1 -• 


NUN 


Char 


9 


D046D 


1 2. 


LOTNUMBER 


Char 


16 


C301 


3. / 


OSSRNUM 


Char 


16 


D330 


12. 


9SERNUM 


Char 


16 


D330 


13. * 


N.2lRSERIAL 


Num 


3 0 


C084 


1 14 * 


NARYEAR 


Num 


2 0 


C083 


is! 


OLDCONDCD 


Char( A 


) 1 


C003E 


' 16. 


NEWCONDCD 


Char( A 


) 1 


C003E 


17. 


ATRSERIAL 


Num 


3 0 


C089 


' IS. 


NARREMARKS 


Char 


40 




' 19. 


TAGL.A3EL 


Char 


30 




1 Index Files: 


Field 


Name 




1 




1 


AMNNIIN 




1 




4 


AMNSERUP 


( increasing 


1 

1 




4 


AIWSERDW 


( decreasing 



i 



I Relation: NAR Serial 

I DBMS Name: AMNARSER. dbf key( NARSERIAL, NARYEAR) 

Field Field Name Type Width Dec DEN 



1. 


* NARSERIAL 


Num 


3 


0 


C084 


1 2. 


* NARYEAR 


Num 


2 


0 


C083 


' 3. 


NARDTG 


Char 


14 




C078 




Index Files: 


Field 




Name 








1 




AMENARSR 
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TABLE 6 

SAMS PHYSICAL FILE STRUCTURES (CONT'D.) 



1 



Relation; Allowances 

DBMS Name: AMALLOW. dbf key( NALC, ACTCLCODE ) 

Field Field Name Type Width Dec DEN 





* NALC 


Char 


4 


C003C 


2 '. 


* ACTCLCODE 


Char( A) 


1 


E303 


3. 


QUANTITY 


Mum 


5 0 




4. 


TRNGALLOW 


Num 


5 0 




5. 


USED/FY 
Index Files: 


Num 

Field 

1 

2 


5 0 

Name 

AMWNALC 

AMWALTP 





Relation: Address 
DBMS Name: AMDADDR. 

Field Field Name 


dbf 

Type 


key(UIC) 

Width Dec DEN 


1. 


SERVCODE 


Char 


1 


K048 


2. 


* UIC 


Char 


5 


A002 


3. 


ACTIVNAME 


Char 


30 


D192 


4. 


LOCATION 


Char 


30 


A045 


5. 


HULLNUMBER 


Char 


8 




6 . 


ROUT I DENT 


Char 


3 


AOOl 




Index Files: 


Field 


Name 








2 


AMDUIC 








3 


AMDACTNM 





Relation: Static Data 

DBMS Name: AMSTDATA. dbf 




key( UIC) 


Field Field Name Type 


Width 


Dec DEN 



1 1. 


UNITNAME 


Char 


45 


D192 


1 2. 


HULLNUMBER 


Char 


8 




3. 


SERVCODE 


Char 


1 


K048 


4 - 


* UIC 


Char 


5 


A002 


5. 


FUNDCODE 


Char 


2 


K022 


1 


MON I TACT IV 


Char 


-L 






Index Files: none 
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TABLE 6 

SAMS PHYSICAL FILE STRLCTL RES (CONT'D.) 



Relation: Data Elements 
DEMS Name: DATAELEM. dbf 

Field Field Name Type 



key( NAME, SOURCE_FIL) 
Width Dec DEN 



1 . * NAME 


Char 


10 


2. PICTURE 


Char 


6 


3. * SOURCE FIL 


Char 


50 


4. DESCRIFIO 


Char 


240 


5. DEN 


Char 


6 


6. LCN3TITLE 


Char 


55 


7. CODES 


Memo 


10 


3. REFERENCE 


Char 


70 


Index Files: 


Field 


Name 




1 


DATANAME 




3 


DATAELSR 


Relation: Contain 


s File 




DEMS Name: CONTFI 


LE. dbf 


key( NAMEOFPROG) 


Field Field Name 


Type 


Width Dec DEN 


1. * NAMEOFPROG 


Char 


8 


2. CONTAINS 


Char 


50 


Index Files: 


Field 


Name 




1 


CONTNAME 


Relation; Systems 


File 




DBMS Name: DICFILES. dbf 


key( FILE_NAME) 


Field Field Name 


Type 


Width Dec DEN 


1. * FILE NAiME 


Char 


8 


2. FILE TYPE 


Char 


d 


3. DESCFIPIO 


Char 


40 


Index Files: 


Field 


Name 




2 


DICFILTP 


Relation: System 

DBMS Name: PROOF I 


Programs 
LE. obf 


key( PROG_NAME ) 


Field Field Name 


Type Width Dec DEN 


1. * PROG NAME 


Char 


8 


2. CALLF 


Char 


100 


3. PURPOSE 


Char 


70 


4. CALLED_BY 


Char 


80 


Index Files: 


Field 


Name 




1 


PROGNAME 
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TABLE 6 

SAMS PHYSICAL FILE STRUCTURES (CONT'D.) 



Relation: User s File 

DBMS Name: DBSYSTEM. db key( GROUP NAME, LOG IN NAM, 

PASSWORD) ~ ~ 

Field Field Name Type Width Dec DEN 



1. GROUP NAME Char 8 

2. * LOG IN NAM Char 8 

3. PAS5wo!^D Char 16 

4. ACCOUNT NM Char 24 

5. ACCESS_LVL Num 1 0 

NOTE: This is a special relation established within 
the PROTECT program of the dBase 1 11+ and is 
encrvp-ced. Ic may only be modified by the DB 
Admiriistrator. Fields one, two, and three are man- 
datory. The access level may be one through 
eight, with one giving the most priveledges. 



major subsystem diagram in Appendix D, we see that the main menu allows the user to 
select one of nine options, each is completely independent of the other. This is an 
example of low coupling which is desireable. Each subsystem then presents another 
menu which will determine what the user desires to do. The SAMS generally has four 
levels of hierarchy in it's application programs: 

1 . The miain menu 

2 . The subsystem menu 

3. The application desired 

4. Utility programs (infrequent) 

Examples of utility programs can be seen in the Requisition .Management subsystem 
under the Print Requisition application module. 

In general, very few parameters are passed in the system. Facilitating this is the 
fact that in dBase III Plus , a called program can manipulate variables in the caller 
program without parameters being passed. This can be convenient, but it can also have 
dangerous implications. The programmer must ensure that the called program does not 
inadvertently alter variables in the main program that were not intended. Of course, by 
not using parameters, a programmer limits the usefulness of his programs by making 
them dependent on a particular application. For further background on parameter 
passing and implicit and explicit inheritance the reader is referred to VlacLennon 
[Ref 24]. 
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Structure charts provide the programmer with a framework for the 
implementation of the various subsystems and individual modules, while the Data Flow 
Diagrams provide a guide to the logical processes of the subsystems. Neither graphical 
representation should be regarded as "cast in concrete" however, the physical 
implementation may suggest modifications. 
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V. IMPLEMENTATION 



A. IMPLEMENTATION PROGRESS TO DATE 

Early in the developement of the SAMS, it was obvious that complete 
implementation and Held testing would be quite impossible in the available research 
time. Therefore the author selected the portions of the implementation that would be 
the most beneficial to anyone continuing the effort, and provide a framework for that 
implementation. 

The design stage identified all of the programs necessary for the SAMS. They are 
listed in the PROG FILE database and may be printed with their associated data by 
running PROGFlLE.prg. Appendix C contains this listing. Approximately one quarter 
of the systems programs have been implemented. 

The Requisition Management subsystem was fully implemented because it's 
programs demonstrate a myriad of programming techniques to accomplish their tasks. 
There are modules to review databases, edit/delete, create documents, print documents, 
backup files, and various forms of interactive programming are demonstrated. Most of 
the other SAMS subsystems use many of these processes, so a close review of the 
Requisition Management programs can significantly decrease the learning curve for 
future programmers. Completed program listings are contained in Appendix E. 

In addition, the database, index, and format files necessary to operate the 
Requisition .Vlanagement subsystem were created and loaded with sample data. 
Testing was performed throughout the implementation of these modules to show 
correct operation, although not exhaustive or as a dedicated separate evolution. 
System testing is obviously a critical phase of the developement process not to be 
slighted. .Module independence will greatly facilitate testing and make rapid debugging 
possible. 

.Many of the system documentation modules were also completed during the 
analysis and design stages and should greatly assist future programmers. These include 
the Data Element Dictionary, structure charts, program files, files directory, and cross 
reference between programs and relations. 
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B. CODING ST^TE 



Without repeating at length the ideas that have been presented throughout this 
paper concerning the interactive style of the SAMS, it nught be worthwhile to bring 
together in one spot the essential points. 

First, SAMS must be easy to use. .Although larger ships may be able to dedicate 
a single person to the responsibility for system operation as a primary duty, this will 
normally not be the case. Therefore the slant should be toward more information, 
rather than less, in the interactive process. This assumes the operator will not be so 
.^amiliar with the system that the e.xtra information will be annoying. The Requisition 
Management option presents tiie user with most of the information that could be 
gleaned .Hrom several publications. The difference is that the publications contain a 
whole range of logistics information, and the S.A.MS will present pertinent information 
chat flee: users need and no more. Therefore, the key phrase is "complete, selective 
Inform.ation". 

The system administrator, or manager, must be knowledgeable of the instructions 
and publications that e.xplain the present system, and the operators must have a 
working knowledge. The manager should understand the basics of dBase III Plus, not 
to the degree of being able to program, but enough to be able manipulate relations 
should a problem arise. Moreover, he should understand the implications of his ability 
to alter those relations. 

Finally, code docuntentation should primarily be contained within the listing 
itself. Placing it here will increase the chances of it being useful to a future miaintenance 
programmier. and it will be easier to maintain of its own accord. Some authors feel that 
source code comments are perhaps the easiest form of documentation to maintain, 
[Ref P: p. 251 and 341], and this author would tend to agree. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The Shipboard Ammunition Management System presented in this thesis is one 
viable alternative to the present system. It automates much of the manual record 
keeping, can prepare useful management reports, and produce external documents 
compatible with the supply system's ADP equipment. 

There are several factors that make a stand alone system difficult to design. First, 
it must be compatible with different processing systems. It must automate manual 
procedures on one hand and on the other hand it must produce documents that are 
compatible with machine readable capabilities of the shore establishment. This 
dichotomy has in part been a reason why the system has been getting more difficult for 
the "customer", the fleet user, to maintain. .Machine readable ATR's mav eliminate kev 
punching errors at the SPCC level, however they are incomprehensible at the user level 
except to the preparer. Every message that leaves a ship should be checked for 
accuracy by at least two people prior to the commanding officer signing his permission 
to transmit, and this could run into considerable manhours if everyone must dig 
through publications to look up "funny codes and formats". 

Thus, a second alternative to solve the problem is to extend automation 
capabilities to all ships from the shore based ammunition management systems. A 
unified system, with one set of rules, would definitely be superior to a fragmented 
system. The professional managers of ammunition ashore would then be able to extend 
their expertise to the fleet, in order to allow the professional users of the ammunition 
to practice that more, and management less. 

A second problem, as this author perceives it, is the overlapping of directives 
between the supply system and the fleet logistics agents. The fleet user should deal with 
one set of rules, perferably one definitive reference. For example, in the Pacific Fleet, a 
submarine weapons officer has three levels of guidance concerning conventional 
ammunition management [Refs. 3,4] and operational force commander instructions. 
Now. there may be good reasons for modifications depending on the theatre of 
operations or weapon type, but the users guidance should come from one place, to 
minimize confusion. Consistently following this policy would probably reduce by one 
third the number of publications that a typical ship is required to carry, in vveight if not 
in number. 
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The Shipboard Non-tactical ADP System (SNAP) is currently being installed on 
NaNy ships in increasing numbers and is designed to handle many supply, maintenance, 
and administrative functions previously done manually. This could provide an excellent 
vehicle to automate the ammunition management function. This thesis and others 
could provide functional, if not design descriptions of such a subsystem to SNAP. 

Finally, if the preceeding alternatives can not be economically or politically 
justified, then a stand alone system, the SAMS, should be pursued. The author 
estimates two to four months of programming would complete the SA.MS application 
programs, then a pilot ship should be selected for the initial installation. The SA.MS 
should run in parallel with the existing manual system to gather user experience, 
document "bugs", and adjust user interface. This phase would be an extremely 
interesting follow-on thesis in itself Ultimately there must be a program olTice for the 
S.A.MS. logically as part of C.-\1.MS at SPCC. to provide guidance and installation 
assistance to the fleet. 

Therefore, the problems of conventional ammunition management can be 
handled in one of three ways: 

1. .An automated system within the CAIMS from SPCC down to all shipboard 
users. 

2. Inclusion of ammunition management in SN.AP. 

3. Stand alone ammunition management - SA.MS 

The goal in selecting any one of the three is to improve and unify the system, and to 
reduce the administrative burden on shipboard personnel. The status quo will not be 
suitable in the long term if we desire an increase in fleet readiness. 
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APPENDIX A 
DATA FLOW DIAGRAMS 
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Inventorv. Allowance. Ammunition Data 
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Level 3 
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APPENDIX B 

DATA ELEMENT DICTIONARY 



DEN: D330 
NAME: CSERNUM 

LONG TaTLc: Component Serial Number (First) 

PIC: X(16) 

Di.SC: The first instance of a serialized component in a transaction 
report, turn-in document, or a NAR action file entry. The 
definition of component serial number is the same data 
element SiRNUHBER. 

USED IN : .AHNARACT , AMIRANS , AMTURNIN 
REFS : 



DEM: D330 
NAME: 15ERNUM 

DONG TITLE: Component Serial Number (Second) 
PIC: X(15) 

DESC: Same as OSERNUli, except second instance. 
USED IN: AMNA.RACT,.^MTRANS, AMTURNIN 
.REFS : 



DEN: D330 
NA.ME: 2SERNUM 

LONG TITLE: Component Serial Number (Third) 
PIC: X(15) 

DESC: Same as OSERNUM, exceot third instance. 

USED IN: .RHNARACT,AMTRANS,A(-1TURNIN 

REFS: 



DEN: D330 
NAME: 3SERNUM 

LONG TITLE: Component Serial Number (Fourth) 
PIC: X(16) 

DESC; Same as OSERNUM, except fourth instance. 
USED IN: .AI-INARACT,AMTRANS, AMTURNIN 
RcFS ; 



DEM: D330 
NAME: 4SERNUM 

LO.MG TITLE: Component Serial Number (Fifth) 
PIC: X(16) 

DESC: Same as OSERNUM, except fifth instance. 

USED IN: .AMN.ARACT,AMTRANS,A1-ITURNIN 

REFS: 



DEN: D330 
NAME: 5SERNUM 

LONG TITLE: Component Serial Number (sixth) 
PIC: X(16) 

DESC: Same as OSERNUM, except sixth instance. 

USED IN: AMNARACT,AMTRANS, AMTURNIN 

REFS: 



DEM: D330 
NAME : 6SERNUM 

LONG TITLE: Component Serial Number (Seventh) 
PIC: X(16) 

DESC: Same as OSERNUM, except seventh instance. 
USED IN: AMNARACT,.AMTRAjMS, AMTURNIN 
REFS : 
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DEN: D330 
NAME: 7SERNUM 

LONG TITLE: Component Serial Number (Eight) 
PIC: a(16) 

DESC: Same as OSERNUM, except eight instance, 

USED IN: ANNARACT,AMTRANS,AMTURNIN 

REES: 



DEN: D330 
MANE: 3SERNUM 

LONG TITLE: Component Serial Number (ninth) 
?;C: X(16) 

DISC: Same as OSERNUN, except ninth instance. 

USED IN: AMNARACT,AMTRANS,AHTURNIN 

REFS: 



DEN: D330 
NAME: 9SERNUM 

LONG TITLE: Component Serial Number (tench) 
PIC: K(16) 

DESC: Same as OSERNUN, except tenth instance. 

USED IN : AMNARACT , AMTRANS , AHTURNIN 

REFS: 



DEM: 

NAME; ACCESSLEV 

LONG TITLE: Access Level 

PIC: 9 

DESC: Determines the level of user access or priveledges within 
the SAMS system; ranging from one to eight with one the 
m.ost powertul and eight the lowest. Used to regulate 
access to various menu options from the main menu. 

USED IN: DBSYSTEM 
REFS: 



DEN: 

NAME: ACCOUNTMAM 

LONG TITLE: Account Name 

PIC: X(24) 

DESC: An optional 24 character field in the users file that 
may be used by the SAMS manager to record the users 
full name or other information. 

USED IN: DBSYSTEM 
REFS: 



DEN: E303 
NAME : ACTCLCODE 

LONG TITLE: Activity Classification Code 
PIC: A 

DESC: Indicates the intended use of ammunition stocks carried 
by a ship or activity. 

USED IN: AMINVEN,AMTURNIN, AMTRANS, AMALLCW 
REFS : 



DEN: D192 
NAME: ACTIVNAME 

LONG TITLE: Activity Long Name 
PIC: X(3C) 

DESC: Name of the activity as listed in the Plain Language 
•Address Directories (PLAD) if available, otherwise 
in the clear name. 

USED IN: AMDADDR 
REFS: 



DEM: KC25 
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NAME: ADVICECODE 
LONG TITLE : Advice Code 
PIC: X(2) 

DESC: Advice Codes are numeric/alphabetic and flow from the 
requisition originators to initial processing points. 
The purpose is to provide coded instructions to supply 
sources when such data is considered essential to 
the supply action. 

USED IN: AMREOUIs 
REFS : 



DEN: 

.N.AME : ATRJULDAT 

LONG TITLE: Ammunition Transaction Report Julian Date (SAMS LDE) 
PIC: 999 

DESC: The julian day of the year on which the ATR was prepared. 

Consists of the three number equivalent of the day of the 
year. 

USED IN: AHT.RANS 
REFS : 



ubW : 

NAME : Ap.REMARKS 

LONG TI-LE: .Ammunition Transaction Reoort Remarks (SAMS LDE) 
PIC: X(150) 

DESC: .Any narrative remarks that may be necessary to place on 
an ATR to clarify a transaction or provide loadout or 
RDD information. 

USED IN: AMTRANS 
REFS : 



DEM: C0S9 
NAME: ATRSERIAL 

LONG TIiLE: .Am.munition Transaction Report Serial Number 
PIC: 9(3) 

DESC: A three digit number assigned to the sequence of an ATR 
report. The numbers run from 001 to 999 and then repeat 
for a oarticular unit. 

USED IN: AMTURNIN,. AMTRANS, AMNARACT 
REFS : 



DEN: 



NAME: .ATRSTATUS 

LONG TITLE: Ammunition Transaction Report Status (SAMS local elem.) 
PIC; A 



DESC: A one character alphabetic code that indicates the 
status of an ATR document. 

USED IN: AMTRANS 
REFS: 



DEN: 

NAME : 3EGBALANCE 

LONG TITLE: Beginning Balance (SAMS local data element) 

PIC: X(5) 

DESC: The inventory balance of a particular ammunition item 
orior to a transaction occuring. 

USED IN: AMTRAI'IS 
REFS : 



DEM : 

NAME: CALLED_BY 

LONG TITLE: Program called by 

PIC: X(S0) 

DESC: The program that calls the program in question. 
USED IN: PROGtILE 
REFS : 
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DEN: 

NAME: CALLS 

LONG TITLE: Program Calls 
PIC: X(iOO) 

DESC: The name of the program(s) that a program calls. 
USED IM: PROGFILE 
REFS : 



DEN : 

MANE: CODES 

LONG TITLE: Data Element Codes 
PIC: memo 

DESC: The CAINS codes associated with a particular data 
element stored in a separate memo field. 

USED IN: DATAELEN 
REFS: 



DEN: COOS 

M.AME: COGSYNBOL 

LONG TITLE: Cognizance Symbol 

PIC: X(2) 

DESC: The Cognizance Symbol is a two position code prefix 
to National Stock Number to identify and designate 
the Inventory Control Point, office; or agency which 
exercises Supply Management of the item. 

USED IN: .AMKOD.ATA 
REFS : 



DEN: C003E 
NAME: CONDCODE 
LONG TITLE: Condition Code 
PIC: A 

DESC: A single alphabetic character which classifies 

material in terms of readiness for issue and use, 
or to identify action underway to change the 
status of the material. 

USED IN: AMINVEN,AMTURNIN,AMTRANS 
REFS: 



DEN: 

NAME: CONTAINS 

LCNG TITLE: Relations used in a program 
PIC: X(50) 

DESC: The relations that are referenced or used by a 
particular program in the SAMS. 

USED IN: COMTFILE 
REFS: 



DEM: K020 
NAME: DEHANDCODE 
LONG TITLE: Demand Code 
PIC: X(A) 

DESC: Demand Code, (R) recurring, (N)non- recurring 
USED IN: AMREQUIS 
REFS: (a),(b),(c) 



DEM: G436 

NAME: DEM 

LONG TITLE: Data Element Number 

PIC: X(6) 

DESC: A six-digit alphanumeric data field used to 

identify data elements resident in the system data 
base. Obtained from NAVSUP Pub 508, Supply 
Management Proaram Standard Data Element Dictionary 
and keyword index. 

USED IN: DAT.AELEH 



110 



REFS: 



DEN: 

NAME: DESCRIPTIO 
LONG TITLE: Description 
PIC: X(40) 

DESC: The meaning of a data element or the content of a 
file . 

CSED IN: DICFILES, DATAELEM 
REFS : 



DEM: KOOl 

NAME: DOCIDENTIF 

LONG TITLE: Document Identifier 

PIC: aXK 

DESC: The document identifier code provides identification 

of each document t*/pe (i.e. requisition, cancellation, 
follcw-uD, transfer, etc. ) 

USED IN: AHREQUiS 
REFS : (A) , (3) , (c) , (d) 

DEM: K0023 
NAME: DOCJULDAT 

LONG TITLE: Document Julian Date 
PIC: 9(4) 

DESC: Identifies the date that the document or requisition 
v;as established. Consists of the units digit of the 
calender year and numeric values equivalent to the 
day of the year (julian date). 

USED IN: AHTRANS 
REFS: 



DEM: K002C 
MAKE: DOCSERNUM 

LOi.'G TITLE: Document Serial Number 
PIC: 9(4) 

DESC: The portion of the Document Number which applies to 
the serial number of the document. Used in the 
Transaction File it can indicate the serial number 
of either a req’uisition or a Turn-in document, 
differentiated oy the transaction code. 

USED IN: AHTRANS 
REFS: 



DEN: K043 
NAME: DOCSVCCOD 

LONG TITLE: Document Service Code (SAI^S local data element) 
PIC: A 

DESC: The service designator portion of the Document 

Number which is required on an issue or receipt ATR. 
Obtained from the requisition or turn_in file. 

USED IN: AHTRANS 
REFS : 



DEM: A002 
NAME: DOCUIC 

LONG TITLE: Document Unit-Identification-Code (SAMS LDE) 

PIC: X(5) 

DESC: The UIC portion of a Document Number that is required 

on an issue or receipt ATR. Obtained from the requisition 
or turn-in file as appropriate. 



USED IN: AHTRANS 
REFS : 



DEN: P255 
NAME: DOTCLASCOD 
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LONG TITLE: Department of Transportation Class Code 
PIC: XX 

DE5C; A code assigned to the classification assigned by the 
Department of Transportation to indicate the type of 
hazard involved when shipping the ammunition item. 
USED IN: AMNODATA 
REFS: 



DEM: 

NAME: ENDBALANCE 

LONG TITLE: Ending Balance (SAMS local data element) 
PIC; X(5) 

DE5C; The inventory balance of a particular ammunition 
item after a transaction has occured. 

USED IN: AIITRANS 
RnFS : 



DEM: C042 
MAME: FEDSUPCLAS 

LONG TITLE: Federal Supply Classification 
PIC: 9(4) 

DESC: A code assigned by the governmaent to designate 

various groups of common use, commercial type items. 
USED IN: AHMODATA 
REFS : 



DEN: 

NA.ME: FILE_NAME 
LONG TITLE: File Name 
PIC: X(S) 

DESC: Name of the file and may be a database file(.dbf), 
or an index file(.ndx), or a format file(.fmt). 
USED IN: DICFILES 
REFS : 



DEN: 

NAME: FILE_TYPE 
LONG TITLE: File Type 
PIC: X(4) 

DESC: Type of file: database( .dbf ) , index file(.ndx), 
format ( . fmt) 

USED IN: DICFILES 
REFS: 



DEN: 

NAME: FRECLASNM 

LONG TITLE: Freight Classification Nomenclature 

PIC: X(32) 

DESC: The proper shipping name prescribed for the material 
as required by Title 49 CFR, Part 172.101, and the 
DOT hazard class(spelled out). Given under the GBL 
Description column in NAVSEA OP2165, 
usually 2-5 word desc. and Class " " Explosive. 

USED IN: AMMODATA 

REFS : 



DEN: K022 
NAME: FUNDCODE 
LONG TITLE: Fund Code 
PIC: XX 

DESC: A two character code which is used to cite accounting 

data on Navy requisitions. Fleet units use fund code Y6 
and shore units use fund code 26. 

USED IN: AMSTDATA 
REFS : 
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DEN: 

NAME : GROU?_NAME 
LONG TITLE : Group Name 
?IC: K(8) 

DESC; An eight character word that must be entered by the 
user of the SAMS in order for the protection 
functions of the system to allow him access 
to the system. 

USED IN; DBSYSTrM 
REFS : 



DEN: D19c 

.NAME : HAZARDMTCD 

LC.NG TITLE: Coast Gaurd Hazardous Material Code 
r 1 : .*. ( 4 ) 

DESC: Classification of military explosives and hazardous 
munitions as determined bv the US Coast Gaurd and 
set forth in NAVSEA 0? 2155 Vol.2. Ammunition aboard 
all classes of ships must be loaded 
in accordance wizh the guidance contained in CG108. 
USED IN: AMHODATA 
REFS : 



DEN : 

NAME : HULLNUMBER 

LONG TITLE: Hull Number of vessel (SAMS local data element) 
?IC: M(3) 

DESC: Hull Number of shio; SSN685 , FF1096 , etc . 

USED IN: AMDADDR,AMSTDAT.\ 

REFS : 



DEN: 

NAME: IDCODE 

LONG TITLE: I.D. Code (SAMS local data element) 

?IC: M(5) 

DESC: The UIC of the issuing unit or a code indicating the 
ACC or other source of the material involved in the 
transaction; or, the UIC of the receiving unit or a 
code indicating the ACC changed to or 
other destination of the material. 

USED IN: AMTRAMS 

REFS: 



DEM: K002B 

NAME: JULIAMDATE 

LONG TITLE: Document Julian Date 

?IC: X(4) 

DESC: Identifies date document or requisition was established. 
The left most digit is the units digit of the current 
year and the right three are the numeric equivalent of 
the dav of the year. 

USED IN: .AMRECUIS,AMTURNIN 
REFS: (a),(b)' 



DEN: .A045 
N.AME: LOCATION 

LONG TITLE: A.ctivity Long Name Location 
PIC: :<( 30 ) 

DESC: Plain Language Address of activity or ship in overhaul 
or a precommissioned vessel. 

USED IN: AMDADDR 
REFS: 



DEN : 

N.AME : LOGIMJ'IAME 
LONG TITLE: Log-in Name 
PIC: M(S) 
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DESC: An eiaht character name that must be entered properly 
by the user of SAMS for the security- functions of the 
system to recognize him as a legal user and allow 
access to the system. 

USED IN: DBSYSTEM 
REFS: 



DEN: 

NAME: LONGTITLE 

LONG TITLE: Long Title (Local SAMS data element) 

PIC : memo 

DESC: Official description of ammunition data as described 

in Stock List of Navy Ammunition, TWOlO-AA-ORD-010 (SPCC) 
USED IN: AMMODATA 
REFS : 



DEN: 

NAME: LONGTITLE 

LONG TITLE: Data Element Long Title 
PIC: X(55) 

DESC: The full title of the data element as used in the SAMS. 
USED IN: DATAELEH 
REFS : 



DEN: C301 
NAME: LOTNUMBER 

LONG TITLE: Ammunition Lot Number 
PIC: X(lo) 

DESC: A number assigned at the time of manufacture or 
assembly to identify a group of rounds of 
ammunition, each component of which is manufactured 
by one manufacturer under uniform conditions and 
v?hich is expected to perform in a uniform way. 

USED IN: AHINVEN,AMTURNIN, AMIRANS, AMNARACT 
REFS : 



DEN: COOSA 
NAME: MATLCONCOD 

LONG TITLE: Material Control Code 
PIC: A 

DESC: The Material Control Code(MCC) is a single alphabetic 
character assigned by the Inventory Manager to 
indicate to field activities that special reporting 
or control requirements may be necessary. Used in 
CAIMS to indicate SLIT controlled item. 

USED IN: AMMODATA 
REFS : 



DEN: C026 
NAME: HDD 

LONG TITLE: Maintenance Due Date 
PIC: X(3) 

DESC: The month and the year of the next scheduled 

maintenance on the item of record(MYY). MDD is 
assigned to serial number and serial and lot number 
controlled items only. 

USED IN: AMINVEN,AMTRANS 
REFS: 



DEM: K082 
NAME: MEDIASTAT 

LONG TITLE: Media and Status Code 
PIC: X 

DESC: The Media and Status Code is a single character 

indicating the type of supply status required and 
the method in which it is to be furnished. 

USED IN: AMREQUIS 
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REFS: (a),(b),(c),(d) 



DEN: CO 7 6 

NAME: ME5SAGEOTG 

LONG TIDIE: Naval Message Date-Time-Group 

?IC: X(14) 

DESC: The standard means of identifying a naval message: 

The DTG identified the day, the hcur(24 hour clock), 
Z(Zulu tim.e), che month, and decade/year of transmittal. 

USED IN: AMTRANS 

REFS : 

na:-ie: momitactiv 

LCMG TITLE: Monitoring Activity (SAMS local data element) 

? I C ; X 

DESC: The shore logistic or operational command which monitors 
a ships logistics traffic and transaction reports. It is 
used in conjunction with the Cognizance Symbol to form 
ihe Distribution Code. 

USED IN: AMSTDATA 

REFS: 



DE.N: CC03C 
NAME: NALC 

LONG TITLE: Naval Ammunition Logistics Code 
?IC: X(4) 

DESC: The NALC is a four character alphanumeris assigned by 
S?CC to conventional ammunition items which do not 
meet the established DoD criteria for DODAC assignment. 
Application of NALC and DODAC are identical. 

USED IN: AMMCDATA, AMALLOW 
REFS: 



DEM : 

NAME: NAME 

LONG TITLE: Name of data element 
?IC: X(10) 

DESC: The name of a data element in the SAI-IS . 
USED IN: DATAELEM 
REFS : 



DEN : 

NAME: NAMEOFPROG 

LC:;G TITLE: Name of Program 

?IC; X(o) 

DESC: The name of a program used in the SAMS. 
USED IN: CONTFILE 
REFS : 



DEN: C073 
NAME: NARDTG 

LONG TITLE: Notice of Ammunition Reclassification Date-Time-Group 
PIC; X(14) 

DESC; The Date-Time-Group of the NAR message 
USED IN: AimRSER 
REFS : 



r.iiilt : I.AKKsniiKAi 

LONG TITLE: Noi:ice of Ainmunition Transaction Remarks (SAMS LDE) 
?IC: X(40) 

DESC: Statement concerning the condition of affected 

axr^unition following a NAR action and/or the reason for 
the NAR action; normally explained on the NAR itself. 
USED IN: ANNARACT 
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REFS : 



DEN: C084 
MANE; NARSERIAL 

LONG TITLE: Notice of Ammunition Reclassification Serial Number 
PIC: 9(3) 

DESC: One of two sub-elements comprising the NAR Number. 

MAR serial serves the two-fold purpose of collecting 
all items reclassified by a NAR action and identifying 
the number of reclassification actions released 
during a given vear. 

USED IN: ANrURNIN,AMNARSER,ANNARACT 
REr S : 



DEN: C083 
NAME: NARYEAR 

LONG TITLE: Notice of Ammunition Reclassification Year 
PIC: 99 

DESC: One of two sub-elements comprising the NAR Number. 

NARYEAR identifiees the decade and year in which the 
Notice of Ammunition Reclassif ication(NAR) was released. 
USED IN: AMTURMIN,AMNARSER,AHNARACT 
REFS: 



DSN: C304E 
NAME : NETE.XPLWT 

LONG TITLE: Net Explosive Weight 
PIC: X(10) 

DESC: The total weight of all active emlosive components of 
an explosive device which includes primary explosives, 
secondary explosives, pyrotechnics, and propellants. 
Data should be expressed in whole numbers 
with the units. (50 LB., 25 KG.) 

USED IN: AMMODATA 
REFS : 



DEN: C003E 

NAME: NEWCONDCD 

LONG TITLE: New Condition Code 

PIC: A 

DESC: The Condition Code of ammunition items involved in a 

transaction after their change in Condition Code as a 
result of the transaction. 

USED IN: AHNARACT 
REFS : 



DEN: D046D 
N.AME: NUN 

LO’JG TITLE: National Item Identification Number 
PIC: X(9) 

DESC: A nine-position non-significant number assigned by the 

Defense Logistic Services Center to each approved item 
identification under the Federal Cataloging Program. 
USED IN: AMREQUIS, AMMODATA, AMINVEN,AMTURNIN,AMTRMS,AMNARACT 
REFS: (a),(b) 



DEN: C003E 
NAME: OLDCONDCD 

LONG TITLE: Old Condition Code (SAMS local data element) 

PIC: A 

DESC: The Condition Code of ammunition items that are involved 
in a transaction prior to their change in Condition Code 
as a result of the transaction. 

USED IN: AHNARACT 
REFS : 
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DEM: 

NAME : PASSWORD 
LONG TITLE: Password 
PIC: X(lo) 

DESC: A sixteen character password of any case that must be 
entered properly by the user of sAMS in order for the 
security* fu'nctions* of the system to recognize him as 
a legal user and allow access to the system. 

USp IN: DBSYSTEM 
REFS : 



DEM : 

NAME: PICTURE 

LCMG TITLE: Picture of a data element 
PIC: M(6) 

DESC: The type of the data element, ie (X)character , 

(9)n"umeric, etc. and the length of the data element. 
USED IN: D.RTAELE.M 
.REFS : 



DEM: KC25 
NAME: FRIORITYCD 

LCMG TITLE: Priority Code (Issue-Priority-Designator) 

PIC: 93 

DESC: .A series of two-digit numeric codes assigned by the 

originator of the document which expresses the relative 
importance of the requisitioned material movement and 
th'e military urgency of the material movement and 
issue transactions. 

USED IN: AHREQUIS 
REFS : 



DEM: 

NAME: PROG_MAME 

LON’G TITLE: Program Name 

PIC; X(3) 

DESC: Name of a orogram in the SAMS. 

USED IN: PROGFILE 

REFS: 



DEN: X024 
M.AME: PROJCODE 
LONG TITLE: Project Code 
PIC: X(5) 

DESC: A code assigned by the military services or DoD to 

identify a specific project of a general or special 
program nature for recognition through out the 
distribution svstem. 

USED IN: AMREQUIS,AMTURMIN 
REFS: (a),(b),(c) 



DEN: 

NAME: PURPOSE 

LONG TITLE : Purpose of a program 
PIC: X(70) 

DESC: The puroose of a program in the SAMS. 
USED IN: PROGFILE 
REFS : 



:EN: 



NAME : 
LONG 

r . 

DESC: 



QU.ANTITY 
TITLE: Quantity 
X(5) 

Quantity in per unit-of-issue amounts. For quantities 
greater than 99999, use an M in the rightmost digit to 
indicate thousands. Normally all positions should be 
filled in, including leading zeros. 
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USED IN: ANREQUIS,AMINVEN,AMTURNIN,AMTRANS,AMALLOW 
REFS: 



DEN: 

NAME: REFERENCE 

LONG TITLE: Data Element References 
?IC: X(70) 

DESC: The Navy or Supply publications which fully describe 
the puroose and use of a data element. 

USED IN: DATAELEM 
REFS : 



DEN: KOIS 
NAME: REQDELDATE 

LONG TITLE: Required Delivery Date 
PIC: 999 

DESC: When used on a requisition, this element consists of 
a three-digit Julian date which indicates the date 
that the material is required by the requisitionee . 
USED IN: AMREQUIS 
REFS: 



DEN : 

NAME: REQUISSTAT 

LONG TITLE: Requisition Status (SAMS local data element) 
?IC: X(aT 

DESC: A local system code to indicate the status of a 
requisition action, ex. incomplete , ready, 
submitted-nct-filled, etc. 

USED IN: AMREQUIS 
REFS: 



DEN: AOOl 
NAME: ROUT I DENT 

LONG TITLE: Activity Routing Identifier 
PIC: X(3) 

DESC: A three digit alphanumeric or alphabetic code 

assigned to Inventory Control Point, Inventory 
Managers, Distribution Points^ and designated storage 
points. Used to indicate the intended recepient, the 
actual shipper, or action orig. activity 
USED IN: AMDADDR 
REFS: 



DEN: C017 
NAME: SECRISKCOD 

LONG TITLE: Security Classification Code 
PIC: X 

DESC; This code designates the degree of physical security 
assigned to an item of supply. 

USED IN: AMMODATA 
REFS : 



DEN: K048 
NAME: SENDTOSERC 

LONG TITLE: Service Designator Code (of requisitionee) 

PIC: X 

DESC: Service Designator Code of requisitionee, PAC, LANT, 
etc.. A code that identifies a service or element of 
a service. 

USED IN: AMREQUIS 
REFS: (a),(b),(c),(d) 

DEN: A002 
NAME: SENDTOUIC 

LONG TITLE: Unit Identification Code of requisitionee 
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PIC: X(5) 

DESC: UIC of requisitionee . Identifies a ship or shore 

activity uniquely in the manner specified by individual 
military services for accounting and other purposes. 
USED IN: AMREQOIS 
REES: (a),(b) 

DEN: K002C 
M.-.NE : SERIAL 

LONG TITLE: Requisition/Turn-in Serial Number 
PIC: 9(4) 

DESC: The oqrtion of the Document Number (DEN K002) which 
applies CO the serial number of the document. Under 
CAINS, ships use sequential numbers 8000-8999 and then 
repeat when necessary. 

USED IN: AMREQUIS,AHTURNIN 
RE.-5: (a),(b),(c) 

DEN: D330 
MANE : SERNUNBER 

LONG TITLE; Component Serial Number 
?IC: X(16) 

DiSC: .An identification number given to each item 

manufactured within a particular lot of a given 
stock number. 

USED IN: A-MINVEN 
REFS : 



DEN: K048 
NAME: SERVCODE 
LONG TITLE: Service Code 
PIC: X 

DESC: A code that identifies a service or element of a 
service . 

USED IN: ANDADDR,ANSTDATA 
REFS : 



DEN: A002 
NAI-!E: SHIPTOUIC 

LONG TITLE: Unit Identification Code of receiving activity 
PIC: X(S) 

DESC: Identifies a ship, shore activity, operational unit. 

agency, contractor, or other organized entity in the 
manner specified by the individual military 
service/agency for accounting or other purposes. 

USED IN: .ANTURNIN 
REFS: 



DEN • 

N.AHE: SHORTTITLE 

LONG TITLE; Short Title of ammunition item (SAMS data element) 
PIC: X(20) 

DiSC: Short description of ammunition item for quick 
reference . 

USED IN: AHMODATA 
REFS: 



DEN: K021 
N.AHE: SIGNALCODE 
LONG TITLE: Signal Code 
PIC: X(.A) 

DESC: This code designates the fields (card columns) which 
contain the intended consignee (ship to) and the 
activity to receive the bills and effect payment 
(bill to). 

USED IN: AI-IREQUIS 
REFS : 
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DEM : 

NAME: SOURCR_FIL 

LONG TITLE: Source File of the data element 
?IC: X(50) 

DESC: The files (relations) in which the data element 
is used. 

USED IM: DATAELEM 
REFS : 



DEM: 

.NAME; STORAGELC 

LONG TITLE: Storage Location (SAMS local data element) 
PIC: M(30) 

DESC: The location onboard a ship where particular 

ammunition items are stored, ex. small arms locker, 
ready service locker. Magazine (compt. number), etc, 

USED IM: .AMINVEM 
REFS : 



DEM: K048 

NAME : SUPADDSERC 

LONG TITLE; Service Designator Code of loadout activity 
PIC: X 

DESC: Supplemental Address Service Designator Code, loadout 
point. A single alpha code that designates a service 
or element of a service, 

USED IN: AMREQUIS 
REFS: 



DEM: A002 
NAME: SUPADDUIC 

LONG TITLE: Unit Identification Code of loadout activity 
PIC: X(5) 

DESC: Supplemental Address UIC, loadout point UIC, 

Identifies a ship or shore activity uniquely in 
the manner specified by its service for accounting 
and other purposes. 

USED IN: AMREQUIS 
REFS : 



DEN : 

NAME: TAGLABEL 

LONG TITLE: Tag Label (SAMS local data element) 

PIC: X(30) 

DESC: A snort narrative that is placed on the label that 
must be attached to NAR affected ammunition to 
explain the conditions under which it may be used 
or if it may be used and to segregate it from other 
unrestricted use ammunition. 

USED IN: AMMARACT 

REFS: 



DEN: CO 10 
NAME: TMDC 

LONG TITLE: Type of Maintenance Due Code 
PIC; A 

DESC: A code indicating the type of maintenance to be 
performed on the item of record. Applies to 
torpedo MK 46 and ALM (Air launched Missiles). 
USED IN: AMMODATA 
REFS : 



DEN: 

l.'AHE: TRMGALLOW 

LO!IG TITLE: Training Allowance (SAMS local data element) 
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PIC: 9(5) 

DESC: The unit-of-issue quantity of a particJilar ammunition 
item that a ship or unit is autnorized to expend in 
a fiscal year for training. Promulgated in the 30000 
series NAVSEA Shiofill Allowance List. 

USED IN: ANALLOW 

REES : 



DEN: 

NA.NE: TURNINST.AT 

LOj'IG TITLE: Turn-in Document Status (SAMS local data element) 

PIC: A 

DESC: The status of a turn-in record line item, 

ex. -incomplete , ready to print or use as an input 
to an .ATR, or ATR action complete. 

USED IN: AMTURIN 

F.i FS : 

DEN: A0C2 

NAME: UIC 

LON'G T.TLE: Unit Identification Code 

PIC: X(5) 

DESC: Identifies a ship, shore activity, operational unit, 
agency, contractor, or other organized entity in the 
manner specified by the individual military 
service/agencies for accounting or other purposes. 

USED IN: AMDADDR,AMSTD.ATA 

REFS : 



DEM: D192 
NAME: UNITMAME 

LONG TITLE; .Activity Long Name (own ship) 

PIC: X(45) 

DESC: Name of own ship as listed in the Plain Language 
Address Directory (PLAD) if available, otherwise 
in the clear name. 

USED IN: AMSTDATA 
REFS : 



DEM: COOS 

M.A.ME: UNITOFISSU 

LONG TITLE: Unit of Issue 

PIC: AA 

DESC: An abbreviation which represents a determinate 
amount or quantity and serves as a unit of 
measurement when issueing the item, ex. BK,EA,etc. 
USED IN; APn-IODATA 
REFS : 



DEN: 3053 
NAME: UMITPRICE 
LONG TITLE: Unit Price 
PIC: 9(10) 

DESC: The price of the individual item of supply per 
unit of issue. 

USED IN: AMMODATA 
.REFS: 



N.AME: USED/FY 

LCMG TITLE: Training Allowance used in current fiscal year (LDE) 
PIC: 9(3) 

DESC: The quantity of a particular ammunition item that has 
a training allowance that has been expended in the 
current fiscal year for that purpose. 

USED IN: AMALLOV; 
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APPENDIX C 

SAMS PROGRAM DIRECTORY 



Program : 
Calls: 


AHSMAIN 

INFOMENU , INVMENU , TRANMENU , REQMENU , NARSHENU , REPTMENU , 
MANGMEMU , TURNMENU 


Purpose : 


Main prg. that branches to all subsystem menus, 
intro, screen. 


Called By: 


PROTECT (dBase III+ security program) 


Program: 
CaliS: 
Purpose : 


BCKUPATR 

none 

Backups ATR file to another storage device for system 
protection. 


Called By: 


TRANMENU 


Program : 
Calls: 
Purpose : 


BCKUPMAR 

none 

Backups NAR Serial and Action File for system 
protection. 


Called By: 


NARSMENU 


Program: 
Calls: 
Purpose : 


3CKUPREQ 

none 

Backups Requisition File to another storage device 
for sys. protection. 


Called By: 


REQMENU 


Program: 
Calls: 
Purpose ; 
Called By: 


BCKUPSYS 

none 

Allows system manager to bacup all system files. 
MANGMENU 


Program: 
Calls: 
Purpose : 


BCKUPTUR 

none 

Backups Turn-in File to another storage device for 
sys*tem protection. 


Called By: 


TURNMENU 


Program: 
Calls: 
Purpose : 


CCMPLREQ 

none 

Offers detailed review of requis. with all pertinent 
data. 


Called By: 


REQMENU 


Program : 
Calls : 
Purpose : 
Called By: 


CRENEWRQ 

none 

Creates new requis. with detailed user instructions 
REQMENU 


Program : 
Calls : 
Purpose : 
Called By: 


CRENWATR 

none 

Allows user to create an ATR record, collects all data 
TRANMENU 


Program: 
Calls: 
Purpose : 
Called BY: 


CRENWTID 

REVWADD 

Creates a turn-in/issue line-entry. 
TURNMENU 



Program: 
Cal!s: 
Purpose : 


DATAELEH 

none 

Allow the user to review the Data Element Dictionary 
of the SAMS. 


Called By; 


IMFGHEHU 


Program ; 
Calls : 
Purcose : 
Called By: 


DOCCODES 

none 

Presents system and CAIMS codes. 
INFOMEMU 


Program : 
Calls : 
Puroose *. 
Called By: 


DOCDEFIN 

none 

Presents system and CAIHS definitions. 
INPOMENU 


Program : 
Calls: 
Purpose : 
Called By: 


DOCFILES 

none 

Presents S.^MS files and their purpose. 
MANGDOC 


Program : 
Calls: 
Purccse : 
Called By: 


DOCPRGS 

none 

Presents SAMS programs and their purpose. 

ma::gmemu 


Program : 
Calls : 
Purpose : 
Called: 


DOCREFS 

none 

Presents system and CAIHS reference documents. 
INFCMENU 


Program : 
Calls : 
Purpose : 
Called By: 


EDITACR 

none 

Allows use to edit or delete non-committed ATR's. 
IRANMENU 


Program: 
Cal^s : 
Purpose : 


EDITREQ 

none 

Allows editing and deleting of non-submitted 
requisitions . 


Called By: 


REQMEMU 


Program: 
Calls ; 
Purpose : 


EDITTURN 

none 

Allows editing or deleting of non-submitted turn-in/ 
issue document. 


Called By: 


TURNMENU 


Program ; 
Cauls : 
Purpose : 


INFOHELP 

none 

Provide system operating help accessible throughout 


Called By: 


program. 

INFOHENU 


Program ; 
Calls: 
Purpose : 
Called By: 


INFOMENU 

INFOTEXT , INFOHELP , DOCCODES , DOCDEFIN , DOCREFS , DATAELEM 
Gives general system info, and help programs. 

Ai’ISMAIN 


Program : 
Calls: 
Purpose : 


INFOTEXT 

none 

Give general system purpose , operation, and other 
information.^ 
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Called By: IMFOHENU 



Projraqm : 

Purpose : 
Called By: 


IMVALLOW 

none 

Disolays Allowance List information to SAMS user. 
INVhENU 


Program : 
Calls: 
Purpose : 
Called By: 


IMVAI^O 

none 

Allows user to review generic ammunition data 
IMVMEMU 


Program: 
Calls : 
Purpose : 


IMVMEMU 

IMVVIEW , INVAMHO , INVALLOW 

Allows user to review generic ammo data , inventory 
status , allowance . 


Called By: 


AMSMAIN 


Program: 
Calls: 
Purpose : 


IMVREPT 

none 

Prints various inventory reports depending on user 
desires . 


Called By: 


REPTMENU 


Program : 
Calls : 
Purpose : 


INWIEW 

none 

Allow user to review onboard inventory with various 
field items. 


Called By: 


IMVMENU 


Program : 
Calls: 
Purpose : 


NANGADHC 

none 

Allows administrator to create ad hoc queries and 
views , 


Called By: 


MAMGMEMU 


Program : 
Calls : 
Purpose : 
Called By: 


HANGARCH 

none 

Allows administrator to archive old records, 
liANGMENU 


Program: 
Calls: 
Purpose : 


HANGDOG 

DOCFILES , PROGFILE , STRUCCRT 

Allows system manager to select various documentation 
files for view. 


Called By: 


MAMGHENU 


Program : 
Calls: 
Purpose : 


HANGEDIT 

none 

Allows administrator to globally edit and delete 
system records. 


Called By: 


HANGHENU 


Program : 
Calls: 
Purpose : 


HANGINIT 

none 

Start-up and initialization instructions for 
administrator. 


Called By: 


HANGHENU 


Program: 
Calls : 


HANGHENU 

HANGEDIT , HAMGSEC , HANGARCH , HANGRECV , HANGADHC , 


Purpose : 


HANGINIT , BCKUPSYS , DOCFILES , DOCPRGS 
Selects type of system management desired 
by system administrator. 
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Called By: AMSMAIN 



Procram : 
Calls: 
Puroose : 
Called By: 


MANGRECV 

none 

Allows administrator to recover system from failure. 
HAInIGHENU 


Procram : 
Calls : 
Purpose : 


MANGSEC 

PROTECT (dBase III+ security program) 

Allows administrator to manage security and 
access system. 


Called By: 


ma:ig::emu ‘ 


Program : 
Calls ; 
Purpose : 


MISCREQ 

none 

Refers user to other doc. for abnormal requis. 
operations 


Called By: 


REQMENU 


Program : 
Calls : 
Purpose ; 


HARSHEMU 

REVMARSF , REVNARAF , PROCNAR , BCKUPMAR 
Allows review of MAR f ile , stockcheck, action 
file uodate, backup 


Called By: 


AMSMAIN ‘ 


Program : 
Calls ; 
Purpose : 
Called By: 


OSRQREPT 

none 

Prints outstanding requisition internal reports. 
REPTMENU 


Program : 
Calls: 
Purpose : 
Called By: 


PRINTATR 

none 

Allows printing of the various types of ATR's. 
TRANMENU 


Program : 
Cal^s : 
Purpose : 
Called By: 


PRINIREQ 

R£Q124S,REWADD 

Allows printing of differant requisition formats 
REQMENU 


Program : 
Calls : 
Purpose : 
Called By: 


PRINTTUR 

none 

Prints turn-in document. 
TURin-IEMU 


Program : 
Calls : 
Purpose : 


PROCNAR 

none 

Processes NAR message: stock check, update inventory, 
retain data 


Called By: 


NARSMENU 


Program : 
Cal.s: 
Puroose : 
Called By: 


PROGFILE 

none 

Allows user to review and print system program file. 
HANGDOG 


Program : 
Calls: 
Puroose : 
Called By: 


REPTMENU 

INVREPT , OSRQREPT , TRALREPT 

Prints various internal system reports. 

AMSMAIN 


Program : 
Calls : 
Purpose : 


REQ1343 

none 

Prints screen display of DD Form 1348 with 



Called By: 


data filled in. 
PRINTREQ 


Program: 

Calls: 


REQMENU 

REVWREQ , COMPLREQ , CRENEWRQ , EDITREQ , HISCREQ , PRINTREQ , 
BCKUPREQ 


Purpose : 
Called By: 


Branches to all requisition processing sub-functions 
ANSMAIN 


Program : 
Calls: 
Purpose : 
Called By: 


REVNARAF 

none 

Allows user to review the NAR Action File. 
NAR5MENU 


Program : 
Calls : 
Purpose ; 
Called By: 


REVNARSF 

none 

Allows user to review the NAR Serial File. 
MARS MENU 


Program: 
Calls: 
Puroose : 
Called By: 


REVWADD 

none 

Allows user to review address file. 
PRINTREQ , PRINTATR , CRENWTID 


Program : 
Calls: 
Purpose : 


REVWREQ 

none 

Offers summary (exec . ) review of all requis. with 
m.ost imp. data. 


Called By: 


REQMENU 


Program: 
Calls: 
Purpose : 


STRUCCRT 

none 

Allows system manager to review the SAMS design 
structure charts. 


Called By: 


HANGDOG 


Program : 
Calls: 
Puroose : 
Called By: 


TRALREPT 

none 

Prints Training Allowance internal reports. 
REPTMENU 


Program; 
Calls: 
Purpose : 
Called By: 


TRANI'IENU 

VIEWATR , CRENWATR , EDITATR , PRINTATR , BCKUPATR 
Selects type of ATR management desired. 
AMSMAIN 


Program : 
Calls : 
Purpose : 
Called By; 


TURl^IMENU 

TURNREV , CRENWTID , EDITTURN , PRINTTUR , BCKUPTUR 
Selects type of turn-in/issue management desired. 
AMSMAIN 


Program : 
Calls : 
Purpose : 
Called By: 


TURNREV 

none 

Allows review of turn-in file. 
TURNMENU 


Program : 
Calls: 
Purpose ; 
Called By: 


VIEWATR 

none 

Allow user to review the ATR file. 
TRANMENU 
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APPENDIX D 

SAMS STRUCTURE CHARTS 




Shipboard Ammuniton Management Svsvtem 
Major Subsystems 
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2.6 




Inventory, Allowance. Ammunition Data 
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Transaction 
Manacj erne n t 
*'TKANMt:NU " 

4.0 




Transaction Management 
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Review 
Address Fi 
"REVWADD 

4 . 5.1 



Requisition 




Requisition Management 
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Review Requis. ■■ * t ■■ ■ ■ t ■ ■■ ^ 

(summary) Manual Review Spell-out 

"REVWREQ" Requis^ Format Address File Numbers 

^ I "REQ1348*' "REVWADD" "SPELLIT 

^ ^ 57. t 5.7.2 5.7.3 




Turn-in Document Management 







N’ARS Management 
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System Management 
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Generate Internal Reports 
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APPENDIX E 

SAMS PROGRAM LISTINGS 



1. AMSMAIN.PRG 



*AHSMAIM . PRG 

*First Version of AMS main program 

'^Written by LT. Steven L. Smith, USN June 4, 1987 

clear all 

set talk off 

set status off 

set safety off 

set deleted on 

set confirm off 

set delimiters on 

set delimiters to "[]" 

clear 

@4,10 to 10,70 double 

@5,22 say " U.S.S. Navy Ship" 

@3,22 say " Shipboard Ammunition Management System" 

@ 1,1 to 20,78 double 

@ 12,27 say "Today is " + cdow(date()) + ", " + cmonth(date( ) ) 
'' " + str(day(date()) ,2) + ", " + str(year(date() ) ,4) 

@13, 10 say "Author: LT. Steven L. Smith, USN " 

@22, 10 say " Press any key to display the Main Menu " 
wait " " 

do while .T. 
clear 
text 

SAMS MAIN MENU 

1. General Information/Documentation 

2. Inventory/Ammunition/Allowance Data 

3. Transaction Management 

4. Requisition Management 

5. Turn-in Document Management 

6 . NARS Management 

7. System Management 

8. Generate Internal Reports 

88. Exit to dBase III Plus Command Level 
99. Exit to MS-DOS Operating System 

endtext 

@ 1,0 to 24,79 double 
@ 3.1 to 3,78 
@ 13,1 to 18,78 

store 0 to MSELECT 

@ 19,22 say " Enter your selection; " get MSELECT picture "99" 
read 

do case 

case MSELECT = 1 
do INFOMENU 
case MSELECT = 2 
do INVMENU 
case MSELECT = 3 
do TRANMENU 
case MSELECT = 4 
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do REQMENU 
case MSELECT =5 
do TURNMENU 
case MSELECT = 6 
do NARSMENU 
case MSELECT = 7 
do MANGMENU 
case MSELECT = 8 
do REPTMENU 
case MSELECT = 88 
clear 

set talk on 
set status on 
set safety on 
set deleted off 
return 

case MSELECT = 99 
clear 
quit 

otherwise 

@ 22,16 say "Not a valid selection--" 

@ 23,16 say "Press any key to try again." 
wait " " 

endcase 

enddo f.T.] 
clear all 
return 



2. BCKUPREQ.PRG 

* BCKUPREQ.PRG 

* This program backs up the requisition file to another storage 

* device for system protection. 

* Written by LT. Steven L. Smith, USN 1 Sept., 1987 
clear 

I 5,15 say "Requisition File Backup" 

7 

text 

This selection will copy the current up-to-date contents 
of the Requisition File to your backup floppy disk. It is 
important to do this after each session in which you change 
the contents of the file, just in case something catastrophic 
happens to the hard disk, 
endtext 

(? 18,5 say "Place the backup floppy disk with the Requisition" 

I 19,5 say "File on it in drive As*^ 

store " " to MCONFIRM 

@ 22,10 say "Are you ready to backup the file? (Y/N)"; 
get MCONFIRM picture "!" 
read 

if MCONFIRM = "Y" 

run BACKUP AMREQUIS.dbf A: 

* run BACKUP AMREQUIS.dbf A: /A 

wait "Backup Complete - Press any key to return" 

else 

return 

endif 



return 
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3. COMPLREQ.PRG 

* COMPLREQ.PRG 

^ Program to view detailed requisition data 

* Written by LT. Steven L. Smith, USN 15 June, 1987 

clear 
clear all 

do while .T. 

§ 1, 10 to 3, 60 double 

@ 2, 15 say "View Complete Requisition Data" 
text 

1. Specific Requisition (* must know serial number *) 

2. All Requisitions (* newest to oldest *) 

3. QUIT 

endtext 

@ 0,0 to 24,78 double 
store " " to CHOICE 

@ 18, 15 say "Enter choice: " get CHOICE picture 
read 

do case 

case CHOICE = "1" 
clear 

store 0 to SELECTION 

0 10,10 say "Enter the requisition serial number:" 
get SELECTION picture "9999" range 8000,8999 
read 
select D 

use AMREQUIS index AMRSERUP,AMRSERDW 
seek SELECTION 

if foundO 
clear 
exit 
else 

@ 14,10 say "That serial number is not in the file:" 

wait 

clear 

endif 

case CHOICE = "2" 
select D 

use AMREQUIS index AMRSERUP,AMRSERDW 

goto bottom 

clear 

exit 

case CHOICE = "3" 
clear 

close databases 
return 

otherwise 

@ 14,10 say "Not a valid selection-" 

@ 15,10 say "Press any key to try again" 

wait " " 

clear 



endcase 



enddo 
select C 

use AMMODATA index AMANIIN 
select D 

do while .not. bof() 

set relation to NIIN into AMMODATA 
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store C->NALC to AMARK 
store C->SHORTTITLE to BMARK 
store C->UNITOFISSU to CMARK 
store C->COGSYMBOL to DMARK 

set relation to 

store SENDTOUIC to EMARK 
store SUPADDUIC to FMARK 

use AMDADDR index AMDUIC 
goto top 
seek EMARK 

if foundO 

store ACTIVNAME to GMARK 
store LOCATION to HMARK 

else 

store " " to GMARK 

store " " to HMARK 

endif 

goto top 
seek FMARK 

if foundO 

store ACTIVNAME to IMARK 
store LOCATION to JMARK 

else 

store " " to IMARK 

store " " to JMARK 

endif 

select A 

use AMSTDATA 
goto top 

store SERVCODE to KMARK 
store UIC to LMARK 

select D 

d 2,5 say "Document Number: " +KMARK+LMARK+" "+; 

(ltrim(str(SERIAL)))+" "+ JULIANDATE 

d 4, 5 say "NALC: "+AMARK 
d 4, 20 say "NUN: "+NIIN 
d 4, 40 say "Short title: "+BMARK 

d 6, 5 say "Quantity; "+QUANTITY 
d 6, 25 say "Unit-of-issue : "+CMARK 
d 6, 48 say "COG Symbol: "+DMARK 

d 8, 5 say "Send to-. "+SENDTOSERC+SENDTOUIC+" , "+; 

rtrim(GMARK)+", "+ rtrim(HMARK) 

d 10, 5 say "Supplemental Address: "+SUPADDSERC+SUPADDUIC+; 

", "+ rtrim(IMARK) +" , "+ rtrim( JMARK) 

d 12, 5 say "Project Code: "+PROJCODE 
d 12, 25 say "Doc. Ident.: "+DOCIDENTIF 
d 12, 47 say "Media/Status Code: "+MEDIASTAT 

d 14, 5 say "Signal Code: "+SIGNALC0DE 
d 14, 24 say "Demand Code: "+DEMANDC0DE 
d 14, 45 say "Advice Code: "+ADVICEC0DE 

d 16, 5 say "Priority Code: "+PRIORITYCD 
d 16, 32 say "Required Delivery Date: "+REQDELDATE 

d 19, 45 say "Requisition Status: "+REQUISSTAT 
d 18, 43 to 20, 68 
skip-1 

if CHOICE = "1" 

d 22, 5 say "Press any key to return" 
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wait " " 
close databases 
return 
endif 

if bof() 

@22, 50 say "End of File" 
endif 

do while .T. 

store " " to MCHOICE 

@22,5 say " (C)Continue , (R)Repeat, (X)Exit " ; 
get MCHOICE picture "!" 
read 

do case 

case MCHOICE = "C" .OR. MCHOICE = "R" 

if bof() 

goto bottom 

clear 

exit 

else 

clear 

exit 

endif 

case MCHOICE = "X" 
clear 

close databases 
return 

otherwise 

@ 23, 20 say "Not a valid selection, press any key.-" 
wait " " 

@ 23, 1 clear 
@ 24, 1 clear 

endcase 



enddo 



enddo 

close databases 
re turn 



4. CRE.NEWREQ.PRG 

* CRENEWRQ.PRG 

Program to create a new requisition 

Written by LT. Steven L. Smith, USN 8 June, 1987 

clear 

set bell off 

clear all 

use AMREQUIS index AMRSERDW,AMRSERUP, AMRREQDD 

@2,15 say " CREATING A NEW REQUISITION" 

@ 1,10 to 3,47 double 

7 

7 

text 

Requisitions require some coded information that is very 
dirficult to remember. Each screen in this subprogram will 
ask you for information and offer a description of the 
information and the choices available to you. Some items 
are mandatory on a requisition, and the screen will tell 
you so, but It will not prevent you from leaving the item 
blank. It is important then that you check to make sure the 
requisition is complete before submitting it. 

endtext 
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7 

7 

wait " Press any key to start entering data" 

@ 5,0 clear 

^ A* Ssrisl NUmJD6r D6Ci.si.On 

goto top 

store 1 to COUNT 

if ( COUNT + SERIAL ) = 9000 
text 



NOTE: The requisition serial numbers have reached 
8999 and should be restarted at 8000 lAW 
SPCCINST 8010. 12D, You'll have the 
opportunity to do that by continuing. 

endtext 

@ 6,5 to 12,70 double 
wait 
clear 
endif 



do while .T. 

@ 0,0 clear to 5,50 

(3 2,15 say "Requisition Serial Number " 

0 1,10 to 3,47 double 
store " " to CHOICE 
store 0 to VSERIAL 

0 9,8 say "The next sequential requisition serial number is: " ; 

+ltrim(str(COUNT + SERIAL)) 

0 10,8 say " Is that serial number O.K.? (Y,N)" get CHOICE ; 

picture "0!" 
read 

if CHOICE = "Y" 

VSERIAL = SERIAL + COUNT 
exit 

else 

if CHOICE = "N" 

0 5,0 clear 
text 

WARNING: A non-sequential serial number should only 
be used when you reach requisition 8999 and need to 
reset the numbers back to 8000 lAW SPCCINST 8010. 12D. 
The system will alert you when this happens. A serial 
number less than the one reported above could be a 
duplicate; the system also attempts to check for 
this . 

endtext 

0 6,5 to 15,75 double 
do while .T. 
store " " to MCHOICE 

0 17,6 say "Do you still wish to choose a serial"; 

+" number other than " + ltrim(str (COUNT + SERIAL)); 

+",(Y/N)?"; . 

get MCHOICE picture "0!" 

read 

if MCHOICE = "N" 
clear 
exit 
endif 

if MCHOICE <> "Y" .AND. MCHOICE <> "N" 

0 22,8 say "That is not a valid response-- 
0 23,8 say "Press any key to try again: " 
wait " " 
clear 
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endif 

if MCHOICE = ”Y" 
do while .T. 
store 0 to VSERIAL 

@22,8 say "Enter the requisition number:"; 
get VSERIAL picture "9999" range 8000,; 

8999 

read 

set index to amrserup,amrserdw,amrreqdd 
seek VSERIAL 

if foundO 
@ 5, 0 clear 

@ 16,20 say "That is a duplicate serial number--" 
@ 17,20 say " Press any key to try again.-" 
wait" " 
else 

exit 

endif 



enddo 



endif 



if MCHOICE = 
exit 
endif 



II Y" 



enddo 



else 

if CHOICE <> "Y" .AND. CHOICE <> "N" 

@ 12,8 say "That is not a valid response--" 

@ 13,8 say "Press any key to try again " 
wait " " 
clear 
endif 
endif 
endif 

if MCHOICE = "Y" 
exit 
endif 

enddo 

close databases 

End Ssridl Numbsr Dscision 

xxxxxxxxxxx Ax:^xA:^:^ EntCT NIIN 

clear 

store " " to VNIIN 

@5,10 say "National Item Identification Number --NIIN" 

@ 4,5 to 6,70 double 

do while .T. 

store " " to CHOICE 

@3, 15 say "Do you know the NIIN of the item you wish to" 

@ 9, 15 say "order?(Y/N) :" get CHOICE picture " 
read 

do case 

case CHOICE = "N" 

■? 

text 

Go to the Inventory Management program from the main 
menu and find the NIIN or the item you wish to order. 

If this is a new item not yet in the database, be 
sure to add it. Contact the SAMS coordinator or 
Weapons Officer if you do not have the access to 
do this, 
endtext 
■> 

wait 
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clear 

close databases 
return to master 



case CHOICE = "Y" 

@11, 10 say "Enter the NIIN (leave out the blanks)"; 
get VNIIN picture "@!" 

read 



use AMMODATA index AMANIIN, AMANALC 
seek VNIIN 



if foundO 



do while .T. 

store " " to HCHOICE 
@ 13, 5 say "That NIIN is for: " 
set heading on 

display NIiN,NALC, SHORTTITLE 



@ 18, 
read 



5 say "Is this the correct item?(Y/N) 
get MCHOICE picture "!" 



M . 



do case 



case MCHOICE = "Y" 

@7,0 clear 
exit 

case MCHOICE = "N" 

7 

text 

Go to the Inventory Management program 
from the main menu to verify the NIIN. 
endtext 

7 

wait 

clear 

close databases 
return to master 

otherwise 

@20, 10 say "That is not a valid response" 
@21, 10 say "Press any key to try again-" 
wait 

@7,0 clear 
endcase 



enddo 



if MCHOICE = "Y" 
exit 
endif 



else 

@15, 10 say "That NIIN is not in the General" 
@16, 10 say " Ammunition Information file." 

7 

text 

Go to the Inventory Management program from the 
main menu and verify that NIIN. 
endtext 

7 

wait 

clear 

close databases 
return to master 



endif 

otherwise 

@ 10, 10 say "That is not a valid response- 
@11, 10 say "Press any key to try again: " 
wait 
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@ 7, 0 clear 
endcase 
enddo 

use AMREQUIS index AMRSERUP ,AMRSERDW,AMRREQDD 
anpend blank 

replace SERIAL with VSERIAL, NUN with VNIIN 
@7, 0 clear 

d 10, 10 say "Requisition serial number " + str(SERIAL) 

@11, 10 say "created for NUN " + NUN 

wait 

2nd NIIN Decislon 

-k-k-k-ki^y^ikTKTK'k-x-kT^T^Tr'k'k'k'k QUj^MTIXY 

close databases 
clear 

@ 1, 10 to 3, 50 double 
@ 2, 25 say "Quantity" 

use Ara-IODATA index AI-IANIIN 
seek VNIIN 

@ 5, 10 say " The unit-of-issue for NIIN " + NIIN + ", " ; 
+ SKORTTITLE + "is: " + UNITOFISSU 



use 

use AMREQUIS index AMRSERUP , AMRSERDW, AMRREQDD 
seek VSERIAL 

store " " to VQUANITY 

text 

The quantity must be given as five digits. So if your 
quantity is less than that, fill in the positions to the 
left with zeros. (Example: quantity 325 would be given as 
00325, 5 would be given as 00005. If you are ordering more 
than 99999, use an "M" in the rightmost position for 
thousands and adjust the other numbers acccordingly . 

Ref: SPCCINST 3010. 12D Para 8-208f. 

endtext 



@22, 15 say "Enter the quantity you desire: " get VQUANITY; 
picture 
read 

replace QUANTITY with VQUANITY 

End QUcintlty DsclsiOn 

7i:xxxxxxx7i::*:x:A:x:*c:^x:*:x:Ar A t*? 

clear 

@ 1, 10 to 3,50 double 

@ 2, 23 say "Julian Date" 

7 

text 

NOTE: The 4 digit iulian date on a requisition that will be 
transmitted by electronic media (radio) must be 
equivalent to the date- time-group on the message, so 
it your radio room or communications center can not 
transmit the message on the day you think they will, 
it might be best to leave the date blank below ( by 
just pressing <RETURN>). Or you could put the date in 
and change it later. 

On a manual requisition, DD form 1348, this 
requirement does not exist, so just put down the date 
you expect to turn in the requisition. 

Julian Date Format: (yDDD) 

Y - last digit of current year (ex. 1987 - 7 ) 

DDD - julian day of year ( use 3M calendar ) 

Ref: SPCCINST 8010. 12D Para 8-208g(3) 



145 



endtext 

■> 

store " " to VDATE 

@22, 15 say "Enter the Julian Date or press <RETURN>: " ; 
get VDATE picture "XXXX" 
read 

replace JULIANDATE with VDATE 

Jullsn DstS DSCiSlOn 

rr-kir-k-k-k-k-k-k-k-k^^-k-k-k Requisition and Loadout Point ********* 
clear 

@ 1, 10 to 3, 60 double 

@ 2, 15 say "Requisition Routing and Loadout Point" 

~> 

text 

Naval message requisitions always go to SPCC Mechanicsburg, 
PA., N00104. Requisitions sent via DAAS format always go to 
DAAS (Defense Automated Addressing System), Dayton, OH. 

(Ref. SPCCINST 8010. 12D) 

However, fleet instructions vary on who should receive 
requisitions if submitted by message(DAAS incl). Therefore you 
should indicate below who will receive the requisition or be 
the primary action addee on a message. This is necessary to 
assign the proper routing identification code. 

The supplemental address is the location where you plan to 
actually receive the material and load it out. You need to 
fill this in so that the supply system will know where to 
send the material and from which supply point to fill the 
order. 

The next screen will show you the most common supply 
activities and vessels in your area ( and beyond ) . 

A complete list is in NAVSuP Pub. 485, App. 7. 

endtext 

wait 

@ 4,0 clear 
close database 

use AMDADDR index AMDUIC 
store " " to VSERVCOD 
store " " to VUIC 

store " " to VSUPSRCD 
store " " to VSUPUIC 



goto top 

do while .not. eof() 

List next 6 SERVCODE,UIC,ACTIVNAME, LOCATION 
if eofQ 

@ 17,10 say "That's all the activities on file." 
endif 



@ 

@ 

@ 

@ 



18.5 say "Enter service code of requisition recepient : " ; 

get VSERVCOD picture "!" 
read 

19.5 say "Enter the UIC of requisition recepient:"; 

get VUIC picture ^XXXXX" 
read 

20.5 say "Enter service code of supplemental address; " ; 

get VSUPSRCD picture " 
read 

21.5 say "Enter UIC of supplemental address: " ; 

get VSUPUIC picture "XXXXX" 
read 



do while .T. 

store " " to CHOICE 



@22,5 say "Want to see more locations or review again? (Y/N)" ; 

get CHOICE picture "!" 
read 
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do case 

case CHOICE = "N" - 

exit 

case CHOICE <> "N" .AND. CHOICE <> "Y" 

(§23,5 say "Mot a valid choice, press any key:" 
wait " " 

(§ 23,1 clear to 23,70 

case CHOICE = "Y" 

(§ 4, 0 clear 
exit 
endcase 

enddo 

if CHOICE = "N" 
exit 
endif 

if CHOICE = "Y" .AND. eof() 
oto top 
4, 0 clear 
endif 

enddo 

use 

use .\NREQUIS index AMRSERUP,AMRSERDW,AMRREQDD 
seek '/SERIAL 

replace SENDTCSERC with VSERVCOD, SENDTOUIC with VUIC,; 

SUPADDSERC with VSUPSRCD, SUPADDUIC with VSUPUIC 

**xKK****xx*x£j^d Requisition Routing/Loadout Point****** 

i^7f’k-k'k7Ki>:-k:k7K-k:k7^yK:k:k9<:-k-k:k ProjSCt CodsS 

clear 

5 1, 10 to 3, 60 double 

@2, 15 say " Project Code " 

7 

text 

Project Codes basically tell what you are requisitioning the 
ammunition for. The most common codes for fleet units are 
shown below, and more complete lists can be found in SPCCINST 
3010. 12D, NAVSUP Pub 485 npp. 6, and in the System 
Documentation section of this program, 
endtext 

7 

7 

wait" Press any key to show project codes:" 

(§4,0 clear 

do while .T. 
text 

Code 
335 



337 



375 



877 



873 



endtext 
wait 
04,0 clear 
text 



Project Title 

Ammunition requisitioned for the replacement of 
service ammunition that was used during annual or 
fleet exercise training. 

Load adjust(shipfill)- Onload/offload of shipfill 
ordnance to/from combatants or MLSF to facilitate 
offload/onload of training ordnance. 

Training. Ammunition requisitioned for or turned in 
following annual training or fleet exercise. 

Ship Loadout. Ammunition requisitioned to fill ship 
service allowance for ship deployment. 

Ammunition Exchange. Ammunition requisitioned and/or 
turned in for exchange due to NAR's, overage 
components, obsolescence, etc. 
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Code 

890 



891 



892 



endtext 
wait 
@4,0 clear 

do while .T. 

store " " to CHOICE 

@ 15,10 say "Do you need to review the codes again? (Y/N) " ; 
get CHOICE picture "!" 
read 
do case 

case CHOICE = "N" 
exit 

case CHOICE = "Y" 
exit 

case CHOICE <> "N" .AND. CHOICE <> "Y" 

@ 17,10 say "Not a valid choice, try again:" 
wait 

@ 17,1 clear to 17, 70 
@ 18,1 clear to 18, 70 

endcase 

enddo 

if CHOICE = "N" 
exit 
endif 

@ 4, 0 clear 

enddo 

store " " to VPROJCOD 

@20, 10 say "Enter the appropriate project code: " ; 

get VPROJCOD picture "!!!" 
read 

replace PROJCODE with VPROJCOD 

ProjsCt CodS DeClSion 
'ki^'k7K7^'k'k'k-k'k-ki^-k-k-k-k-k:k-k DoCUIHCnt Identifier 

clear 

@ 1,10 to 3, 50 double 

@2, 15 say " Document Identifier" 

■? 

text 

The document identifier identifies the purpose of the 
document rapidly to the data entry personnel at the supply 
activities and can be recognized By automated machinery which 
processes many supply documents these days. By purpose it is 
meant requisition, issue, status, cancellation, etc.. 

More information and complete lists of document identifiers 
are contained in: SPCCINST 8010. 12D Para. 8-208 2(a) and 
NAVSUP Pub 485 App. 4. (* MANDATORY ITEM *) 

endtext 



wait" Press any key to view choices and make selection:" 
@ 4, 0 clear 

text 

Doc. Iden. Meaning 

AOl For delivery outside CONUS with NSN 



Pro 3 ect Title 

New Construction. Initial onload(reqn. ) of 

ammunition for newly constructed or activated ships. 

Ship Overhaul. Down load( turn-in) of ammunition 
prior to entering yard for overhaul and onload 
(reqn.) of such ammunition upon leaving the yard. 

Ships Restricted Availability. Ammunition off-loaded 
(turned-in) required by entering a restricted 
availability period and the subsequent onload( reqn. ) 
of ammunition upon completion. 
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A04 For delivery outside CONUS with NALC-NIIN 

AOA For delivery within CONUS with NSN 

AOD For delivery within CONUS with NALC-NIIN 

* AOS For delivery outside CONUS w/exception data 

ACE For delivery inside CONUS w/exception data 

-- Can't be used for DAAS NSN = FSC + NUN 

endtext 

store •' " to VDOCIDEN 

@22, 10 say " Enter the appropriate document identifier: " ; 

get VDOCIDEN picture "!!!" 
read 

replace DOCIDENTIF with VDOCIDEN 

:k:k-k^:k:kiK-k^i^-kiK-k:kik-k'k’k-k7:-k - doCUITient Identifier 

MedlS SHd StStUS Code 

clear 

@ 1, 10 to 3,60 double 
I 2,15 say " Nedia and Status Codes " 

? 

text 

The Media and Status Code is used by the supply system to 
determine what type of status should be given regarding the 
processing of the requisition; who should receive this status 
and by what kind of communications transmission this status 
should come. Complete information on this code is contained 
in NAVSUP Pub 485 App. 16. (* MANDATORY *) 

endtext 

7 

7 

wait" Press any key to show more amplifying information:" 

@ 4, 0 clear 

do while .T. 
text 

Definitions : 

(a) EXCEPTION STATUS will be used to request information 
relative to any action taken by the supply source other 
than issue of the material. 
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(b) 100% SUPPLY STATUS will be used to request information 
relative to any action taken by the supply suorce 
including release of material tor shipment, but not 
including bill of lading numbers or mode of shipment. 

(c) SHIPMENT STATUS may be used in conjunction with 
exception status or 100% supply status to request positive 
information of shipment, including date of shipment, mode, 
bill of lading, or airway bill number, as applicable. 

Supply status for ammunition requisitions will be provided 
to both the requisitioner and the supplemental addressee, 
provided one is given, 
endtext 



v;ait" Press any key to view choices*. " 



@ 4, 0 clear 
text 

M&S Code 
0 
2 
3 

* B 
C 



Definition 
No status provided 

Provide exception status via AUTODIN 
Provide exception status by mail 
Provide 100% supply and exception status 
by AUTODIN ‘ 

Provide 100% supply and exception status 
by mail 
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K 



L 

M 

* S 

* T 

* 

endtext 

wait 

@ 4, 0 clear 



Provide exception and shipment status 
by AUTODIN 

Provide exception and shipment status 
by mail 

Provide exception and shipment status 
by message 

Provide 100% supply and shipment status 
by AUTODIN 

Provide 100% supply and shipment status 
by mail 

-- Required for priorities 01 - 08 



do while .T. 



store " " to CHOICE 

@6, 10 say "Do you need to see the definitions again? (Y/N) " ; 
get CHOICE picture "!" 
read 



do case 



case CHOICE = "Y" 

@4,0 clear 
exit 

case CHOICE = "N" 
exit 

case CHOICE <> "N" .AND. CHOICE <> "Y" 
@ 10,10 say "Not a valid choice:" 
wait 

@ 10,5 clear to 10,70 
@ 11,0 clear to 11,70 

endcase 

enddo 

if CHOICE = "N" 
exit 
endif 

enddo 



store " " to VHEDSTAT 

@15, 10 say " Enter the appropriate M&S Code: " ; 
get VHEDSTAT picture "!" 
read 

replace MEDIASTAT with VMEDSTAT 
***x*****x********* Etid Media and Status Code Decision **** 

DenicUld Cod6 

clear 

@ 1, 10 to 3,50 double 
@2,15 say "' Demand Code " 

text 

At last a simple code! 

R - Recurring demands. Use when item requisitioned 
is for shipfill ammunition. 

N - Non-recurring demands. Use when item 

requisitioned is clearly a "one-time" request, 
or is the initial loadout of the ship when 
commissioned. 

Ref; NAVSUP Pub 435 sec. 3023, 3024 

endtext 

7 

7 

store " " to VDEMCOD 

@ 20,10 say " Enter the appropriate letter: 
get VDEMCOD picture "I" 
read 

replace DEMANDCODE with VDEMCOD 
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*x:it*x*xxxKrxx**w** Demand Code ************************** 

x:^*xx*xxA***x**:^* Sional Code ************************ 
clear 

t? 1,10 to 3,50 double 
5 2,15 say " Signal Code" 



text 

The signal code is used to identify the activity to which the 
material is to be shipped and/or billed. 

Ref: NAVSUP Pub 485 .^^pp 14 (* MANDATORY *) 

Signal Code Meaning 



A 

3 

J 



K 



Ship and bill to requisitioner 
Ship to requisitioner and bill to 
supplemental address 
Ship to supplemental address and bill 
to requisitioner. Use Signal Code J 
when when the supplemental address is 
used to denote the loadout activity. 
Ship and bill to supplemental address 



endtext 



store " " to VSIGCOD 

(§22, 10 say " Enter the Signal Code-. " get VSIGCOD picture "!" 

read 



replace SIGNALCODE with VSIGCOD 

•k’k'ki<:-k-k7r9ri<:'k-ki^-k'k'k-k Signal Cod6 

Priority Cod0 ( DeslgnStOr) 

clear 

@ 1,10 to 3,60 double 

@2,15 say " Priority Code (Designator) " 

text 

The Priority Code (0-15) expresses the relationship between 
the requisitioner ' s assigned force/activity designator and 
the selected urgency of need designator, and determines the 
time frame within which the requisition will be processed. 
Basically it determines how big a wig you are and how fast 
they have to fill your order! If you don't know your unit's 
assigned force/activity designator check with the Supply 
Officer. The chart on the next screen will help you determine 
your priority code. Priority Codes are fully explained in 
NAVSUP Pub 485 sec. 3045-3049, it is worth reading once. Your 
unit can generally only use 3 of the Priority Codes since you 
have one assigned F/AD(Force/Activity Designator). 

endtext 

7 

wait " Press any key to see the PD table:" 

@ 4, 0 clear 

7 

text 

Priority Code Table 



Urgency of Need Designator! Force/Activity Designator 





1 




I 


II 


III 


IV V 


A 


(Unable to perform) 1 


01 

1 


02 


03 


07 


08 


B 


(Performance Impaired) | 


I 

04 

1 


05 


06 


09 


10 


C 


(Routine ) j 


I 

11 


12 


13 


14 


15 



endtext 
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store " " to VPRIRCOD 

@ 20 , 10 say "Select an appropriate priority code: " : 
get VPRIRCOD picture "XX" 
read 

replace PRIORITYCD with VPRIRCOD 

Priority CodS 

?*t**:*:*:^c*:Ar****:i«c**:»r:*::^**f^ 0 q^ Delivery Dste ( RDD ) *^******** 
clear 

d 1, 10 to 3, 60 double 

d 2, 15 say " Required Delivery Date (RDD) " 
text 

The RDD is the date that you require the material onboard 
and/or the date of the loadout. It is the 3 digit julian 
day of the year (DDD). They figure out the year from the 
rest of the requisition! (* MANDATORY 

endtext 

■p 

store " " to VJDATE 

@20, 10 say " Enter the Required Delivery Date: " ; 
get VJDATE picture "XXX" 
read 

replace REQDELDATE with VJDATE 
*:A:x7C7c:Af R0CJUired DfilivSry DStC 

AdviC 6 CodfiS 

clear 

@ 1,10 to 3,50 double 
@2,15 say " Advice Codes " 

? 

text 

An advice code may be entered on the requisition to provide 
the supply source with special insrtuctions to ensure 
appropriate supply action is taken. The codes listed on 
the next screen are the only advice codes that may normally 
be used by Navy units to order ammunition. SPCCINST 
8010. 12D lists a few others that may be used when 
authorized by higher authority. NAVSUP Pub 485 App. 1 gives 
complete information on Advice Codes, but note that only 
those listed in the SPCC inst. may be used for ammunition. 
Advice code may be left blank. 

endtext 

@ 20, 10 say "Press any key to view choices-- " 



Description 

Do not substitute/interchange. Requested 
item only will suffice. 

Do not back order. Reject all unfilled 
quantities not available to meet RDD. 
Suitable substitute acceptable. 

Furnish exact quantity requested (do not 
adjust to unit pack quantity) 

Do not substitute or backorder. 

Deliver to the requisitioner by the RDD 
or cancel requirement. 



store " " to VADVCOD 

d 22, 10 say " Enter Advice Code (if desired): " get VADVCOD; 

picture " ! ! " 



wait " " 

@4,0 clear 
text 

Code 

2B 

2C 

2D 

2J 

2T 

endtext 
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read 

replace ADVICECODE with VADVCOD 
X X A X ^ End AdviC0 CodC 

xx:Ar7^X7C7C7^:*r7tX7^7Cx:*:7*c7k7^ Requisition StStUS 

clear 

@ 0,10 to 2,55 double 
I 1,15 say " Requisition Status " 

text 

Requisition Status indicates the degree to which a 
requisition is complete, ready for submission, submitted but 
unfilled, etc.. It is a code established by this system 
(SAMS), and not the Navy supply system. The Navy supply 
system has many status codes or its own. This requisition 
status is for your use in managing your conventional 
a.Tuniunition requisitions, receipts, etc.. It will be used in 
SAMS in various ways. 

MOTE: The only item that may be left blank on a requisition 
you submit is the Advice Code. Therefore it is a good 
habit to simply assign appropriate values to all items 
that this program has requested. 

The next couple of screens will show you all the selections 
that you have made, the exact meaning of the status codes, 
and ask you to assign one. All the values shown have been 
written to the file, so in order to change any values we'll 
finish this part of the program and select the edit option 
from the "Requisition Management" menu, if desired, 
endtext 
wait 

©3,0 clear 

© 4,10 say "Requisition Values Assigned" 

©7, 10 say "Serial Number = " + str(SERIAL) 

©3,10 say "NUN = " + NUN 

© 9, 10 say "Quantity = " + QUANTITY 

©10, 10 say '^Julian Date = " + JULIANDATE 

© 11,10 say "Send to service code = " + SENDTOSERC 

© 12,10 say "Send to UIC = " + SENDTOUIC 

© 13,10 say "Supolemental address service code = " + SUPADDSERC 

© 14,10 say "Supplemental address UIC = " + SUPADDUIC 

©15, 10 say "Project Code = " + PROJCODE 

©16, 10 say "Document Identifier = " + DOCIDENTIF 

© 17,10 say "Media and Status Code = " + MEDIASTAT 

©13, 10 say "Demand Code = " + DEMANDCODE 

©19, 10 say "Signal Code = " + SIGNALCODE 

©20, 10 say "Priority Code = " + PRIORITYCD 

©21, 10 say "Required Delivery Date = " + REQDELDATE 

©22, 10 say "Advice Code = " + ADVICECODE 

wait "Press any key to see codes and assign one: " 

© 3, 0 clear 
text 

Code 
I 



R 

U 



P 



F 

C 

endtext 



Meaning 

Incomplete. Some mandatory fields are missing 
or you are not ready sxibmit it. 

Ready. Requisition is ready for submission. 

Unfilled. Requisition has been submitted but 
is unfilled. 

Partial. Requisition has been submitted and is 
partially filled. 

Filled. Requisition fully filled. 

Cancelled. 



store 



to VREQSTAT 
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@22, 10 say " Enter Requisition Status code; " get VREQSTAT; 

picture " ! ! ! " 
read 

replace REQUISSTAT with VREQSTAT 

waifPress any key to return to Requisition Management menu:" 

Eiid R6quisition Status 

End CRENEWRQ . PRG 

close databases 
set bell on 
return 



5. DATAELEM.PRG 

* DATAELEM.PRG 

* This program allows the user to review the Data Element 

* Dictionary and print it if desired. 

* Written by LT. Steven L. Smith, USN 31 July, 1987 

* Activate next two items if program used alone, 
set talk off 

set status off 
set bell off 

do while .T. 
clear 

@ 5,15 say "SAMS Data Element Dictionary" 

@ 4,10 to 6,48 

7 

7 



text 

What would you like to do? 

1. Review the Data Element Dictionary 

2. Print the Data Element Dictionary 

3. Quit 

endtext 



store 0 to GITEM 

@ 20,10 say "Enter Choice: " get GITEM picture "9" range 1,3 
read 



do case 

case GITEM = 1 
@7,0 clear 

use DATAELEM index DATANAME 
do while .T. 



@8,2 say "DEN: 

@ 9,2 say "NAME: 

@10,2 say "LONG TITLE; 
@ 11,2 say "PIC; 

@12,2 say "DESC: 

@ 18,2 say "USED IN: 

@ 19,2 say "REFS: 



"+DEN 

"+NAME 

"+LONGTITLE 

"+PICTURE 

"+trim(DESCRIPTIO) 

"+trim(SOURCE_FIL) 

"+trim(REFERENCE) 



skip 

if eof() 

@ 23,60 say 
endif 



"End of File" 



do while .T. 



store " " to XCH 

@22,5 say "(C)Continue (R)Repeat (X)Exit; " 
get XCH picture "!" 
read 

do case 

case XCH = "C" .OR. XCH = "R" 
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if eof() 
goto top 
endif 

@ 7,0 clear 
exit 

case XCH = "X" 
use 

@7,0 clear 
exit 

otherwise 

@ 23,5 say "Invalid selection. Press a key--" 
wait" " 

@ 22,0 clear 
endcase 

enddo 

if XCH = "X" 
exit 
endif 



enddo 



case GITEM = 2 



clear 

@ 10,10 say "Ensure printer is on, and press a key to start:" 
wait" " 
clear 

@ 12,20 say "Printing, do not disturb" 

@ 11,15 to 13,50 double 
use DATAELEM index DATANAME 
set device to print 

@1,10 say "SAMS Data Element Dictionary"+chr (10) 

@ prow(),0 say " ^ 

_"+chr(10 ) 



3 prow( ) , 0 say 



_"+chr(10) 
do while .NOT. eof() 



@ prow()+2,2 say "DEN; " 
@ prow(},2 say "NAME: " 

@ prow(),2 say "LONG TITLE: 
+chr(10) 

@ prow( ) , 2 say "PIC : 

@ prow(),2 say "DESC: 
+cnr(10 ) 

@ prow()+6,2 say "USED IN: 
+cnr (10) 

@ prow(>,2 say "REFS: 
+chr(10) 

@ prow(),0 say " 

<^+chr(lQ) 



+DEN+chr(10) 

+NAME+chr(10) 

" + (LONGTITLE) ; 

"+PICTURE +chr(10) 
"+trim(DESCRIPTIO) ; 

"+trim(SOURCE_FIL) ; 

"+trim(REFERENCE) ; 



skip 

enddo 



use 

set device to screen 



case GITEM = 3 
clear 

set talk on 
set status on 
set bell on 
return 

endcase 



enddo 
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return 



6. EDITREQ.PRG 



* EDITREQ.PRG 

* This program allows editing and deleting of certain 

* requisitions 

* Written by LT. Steven L. Smith, USN 16 June, 1987 

do while .T. 
clear 

close databases 

@1, 10 to 3, 60 double 

I 2, 15 say "Editing and Deleting Requisitions" 
text 

What would you like to do? 

1. Edit or Change 

2. Delete 

3. Return to previous menu 

NOTE: For obvious reasons you can only delete or edit a 
requisition that has not been submitted. Therefore this 
program will check to make sure that the requisition 
you select has a status code of (I)Incomplete or 
tR) Ready. 

endtext 



store 0 to CHOICE 

@20, 20 say "Enter your choice: " get CHOICE picture "9"; 
range 1,3 
read 

if CHOICE = 3 
return 



else 



@ 4, 0 clear 
store 0 to NUMBER 

§ 8, 10 say "What is the serial number of the" 

@9, 10 say "requisition that you want to edit" 

@ 10,10 say "or delete?" get NUMBER picture "9999"; 

range 8000,8999 

read 



s s Xcc A 

use AMREQUIS index AMRSERUP ,AMRSERDW,AMRREQDD 
select B 

use AMMODATA index AMANIIN 
select A 

set relation to NIIN into AMMODATA 
seek NUMBER 



if foundO 

@ 12,10 say "Requisition "+ltrim(str (NUMBER) )+" is for:" 

0 13,10 say B->SHORTTITLE 

0 14,10 say " NALC: "+B->NALC+" NIIN: "+NIIN+" QUANTITY: " ; 
+QUANTITY 

do while .T. 

store " " to MCHOICE 

0 16,15 say "Is this the correct item?(Y/N)" 

get MCHOICE picture "!" 

read 

do case 
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case MCHOICE = "Y" 
exit 

case MCHOICE = "N" 

@ 18,15 say "Return to Requisition Management main" 
d 19,15 say "menu and check serial number with" 
d 20,15 say "option 1 or 2." 

? 

wait 

clear 

close databases 
return 

otherwise 

d 18,15 say "Not valid selection, press " 
d 19,15 say "any key to try again:" 
wait'" " 
d 16,0 clear 

endcase 



enddo 

if REQUISSTAT <> "I" .AND. REQUISSTAT <> "R" ; 

.a^D. REQUISSTAT <> " " 
d 18,15 say "That item may not be edited or " 
d 19,15 say "deleted!" 

wait 

clear 

close databases 
return 
endif 

if CHOICE = 1 
clear 

text 

WARNING: Do not change the serial number on this 
requisition because this program does not check for 
duplicate numbers like the program that originally 
created it. ( option 3 ) 
endtext 
■? 

wait 

clear 

set format to ADDREQUI 
read 

close format 
endif 

if CHOICE = 2 

delete record recno() 

set talk on 

pack 

set talk off 
endif 

else 

d 12,10 say "Requisition "+ltrim(str(NUMBER) )+" is not found 
d 13,10 say "in the file. Return to the Requisition" 
d 14,10 say " Management main menu and check serial" 
d 15,10 say " number with option 1 or 2." 

■> 

wait 

clear 

close databases 
return 

endif 



endif 



enddo 
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7. MISCREQ.PRG 

*MISCREQ.PRG 

* This program gives miscellaneous information about 
^requisitioning. 

” Written by Lf. Steven L. Smith, USN 14 June, 1987 
clear 

close databases 



@ 1, 3 to 3, 76 double 

d 2, 8 say "Cancellations, Follow-up, Modifications, Misc. Info" 
text 

I. General. 

Cancellations, follow-ups and modifications to 
requisitions are infrequent events that you may someday 
have to do. Since these are not common, this program 
only refers you to the publications that deal with them. 
The SAMS program will still be useful to you in creating 
these documents. 



IMPORTANT ** Note that the fleet commanders and 
operational commanders promulgate specific instructions 
concerning ammunition requisitioning and reporting. As 
weapons personnel you should keep current on these 
because they deal with your ship's particular area of 
operations . 

Specifically: 



endtext 

wait 

d 4, 0 clear 

■> 

text 



Pacific Fleet - (a) CINCPACFLTINST 8010.12 

"Pacific Fleet Conventional Ordnance 

Management Manual" 

section 1 and appendices 1-10 

(b) COMSUBPACINST C8500.1 
''COMSUBPAC Ordnance Notes" 



Atlantic Fleet - (a) CINCLANTFLTINST 8010.4 

"Atlantic Fleet Reporting an 
Requisitioning Guide" 

(b) 

endtext 

wait 

d 4, 0 clear 

•> 

text 

II. Requisition Follow - Up 

(a) SPCCINST 8010. 12D, Section 8 - 215 

(b) NAVSUP Pub. 485, chap. 3, part D, section II, 

subsection 1, 3530 - 3537 

III. Requisition Modifications 

(a) SPCCINST 8010. 12D, section 8 - 213,214 

(b) NAVSUP Pub. 485, Chap. 3, part D, section II, 

subsection 2, 3550 - 3552 

IV. Requisition Cancellation 

(a) SPCCINST 8010. 12D, section 8 - 216 

(b) NAVSUP Pub. 485, chap. 3, part D, section II, 

subsection 3, 3565 - 3573 



endtext 

wait 

d 4, 0 clear 
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■> 

text 



V. MILSTRIP Status Documents 



(a) SPCCINST 8010. 12D, section 8 - 212 

(b) NAVSUP Pub. 485, chap. 3, part D, section I, 

3506 - 3511 

These documents or messages that the supply system 
provides you are in response to the status you requested 
via the Media and Status code on your requisition. 

VI. Supplemental Requisition Procedures 

(a) SPCCINST 8010. 12D, section 8 - 217 



endtext 
@ 4, 0 clear 

7 

text 



1. 8E cog material - Air launched missile material 

( HARPOCN ) 

2. 8T cog material - Surfaced launched guided 

missile material 



3. *4T cog material - Torpedoes and components 

ASROC 

*8S cog material - SUBROC material 
*8U cog material - Sonobouys 

* Refers you to Fleet instructions 

4. 2D cog material - Tomahawk 



endtext 

wait "Press any key to return to Requisition Management menu 
return 



8. PRINTREQ.PRG 

* PRINTREQ.PRG 

* Program to print requisition documents 

^ Written by LT. Steven L. Smith, USN 16 June, 1987 

store 1 to REQNO 
"^set talk on 
*set echo on 
*set step on 

do while .T. 
clear 

close databases 

@1, 10 to 3, 60 double 
@ 2, 15 say "Printing Requisitions" 

7 

text 

What kind of requisition format would you like? 

1. Manual { DD Form 1348 ) 

2. Naval message 

3. DAAS message 



4. Return to previous menu 

endtext 

store 0 to CHOICE 

@20, 20 say " Enter your choice: " get CHOICE picture "9"; 
range 1,4 



159 



read 

if CHOICE = 4 
return 
endif 



X75**** Look up requisition and load data into variables**** 



@4,0 clear 
store 0 to NUMBER 

@8, 10 say "What is the serial number of the" 

@ 9, 10 say "requisition that you wish to print?"; 

get NUMBER picture "9999" range 8000,8999 

read 

select A 

use AMREQUIS index AMRSERUP 

S 6 1 6 C ^ 5 

use AMMODATA index AMANIIN 
S6 t A 

set relation to NUN into AMMODATA 
seek NUMBER 
if foundO 

@ 12, 10 say "Requisition "+ltrim(str(NUMBER) )+" is for:" 

@ 13,10 say B->SHORTTITLE 

@14, 10 say " NALC: "+B->NALC+" NUN: "+NIIN+; 

" QUi^TITY: "+QUANTITY 

do while ,T. 

store " " to MCHOICE 

@ 16,15 say "Is this the correct requisition? (Y/N) " ; 
get MCHOICE picture "!" 
read 

do case 

case MCHOICE = "Y" 
exit 

case MCHOICE = "N" 

@18, 15 say "Return to Requisition Management main" 
@19, 15 say "menu and check serial number with" 
@20, 15 say " option 1 or 2." 

wait 

clear 

close databases 
return 

otherwise 

@ 18,15 say "Not a valid selection, press " 

@19, 15 say "any key to try again: " 
wait" " 

@ 16, 0 clear 

endcase 



enddo 

if REQUISSTAT = "I" 

@ 18,10 say "WARNING: This item's requisition status " 

@ 19, 10 say "indicates it is not ready for submission. " 
@20, 10 say "Recommend checking an/or updating status." 
wait 
clear 

close databases 
return 
endif 



store B->FEDSUPCLAS to APROD 
store B->COGSYMBOL to BPROD 
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store B->UNITOFISSU to CPROD 
store B->SECRISKCOD to XPROD - 

set relation to 

store SENDTOUIC to DPROD 
store SUPADDUIC to EPROD 

select C 

use AMDADDR index AMDUIC 
goto top 
seek DPROD 

if foundO 

store ACTIVNAME to FPROD 
store LOCATION to GPROD 
store HULLNUNBER to YPROD 
store ROUTIDENT to ZPROD 
else 

store " " to FPROD 

store " " to GPROD 

store " " to YPROD 

store " " to ZPROD 

endif 

goto top 
seek EPROD 

if foundO 

store ACTIVNAME to HPROD 
store LOCATION to IPROD 
else 

store " " to HPROD 

store " " to IPROD 

endif 

use 

select D 

use AMSTDATA 
store SERVCODE to JPROD 
store UIC to KPROD 
store Itrira(UNITNAME) to LPROD 
store HULLNUMBER to HPROD 
store FUNDCODE to NPROD 
store HONITACTIV to OPROD 
use 

select A 

endif 

if .not. foundO 
clear 

(s> 12,15 say "Requisition "+ltrim(str(NUMBER) )+" is not" 
13,15 say "found in the file. Return to the " 

@ 14,15 say "Requisition Management main menu and " 
d 15,15 say "check the serial number with options " 

I 16,15 say " 1 and 2." 

wait 

clear 

close databases 
return 

endif 

********Finished loading requisition data into variables*** 
****** Process manual requisition DD Form 1348 ******* 

if CHOICE = 1 
clear 

@ 1, 15 to 3, 50 

0 2, 20 say "Manual Requisition" 

text 
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Notes: A DD Form 1348 can not be produced on most common 
computer printers because of its size and lack of 
tractor feed holes. In any case you would have to 
remove the normal paper. 

This program will produce a near replica of the 
completed DD Form 1348 on the screen and then you 
will have to transfer the exact data to the DD 
Form 1348(6-part) card. 

You should use a black ball point pen, pressing 
firmly, or use a typewriter set at 10 pitch. 
Attempt to keep the characters within the ‘'tick- 
marks". Use 0 (with a slash through) for the 
number zero, 
endtext 

7 

wait 

do REQ1348.PRG 

@ 20,10 say "Press any key to return-" 
wait " " 



endif 

******** Finished processing manual requisition ******** 

****Process information common to DAAS and narrative messages * 

if CHOICE =2 .OR. CHOICE = 3 
clear 

@ 0,15 to 2,60 double 

@1,25 say "Special message information" 



text 

NOTE: During periods of restricted communications ( ie 
MINIMIZE), message requisitions shall only be transmitted 
for priorities 01-08 requirements, 
endtext 
@ 3,2 to 8,75 



****** special addressing info, for certain COG material 

text 

Comments: The action and info addees on naval message 
requisitions vary widely depending on the type of material 
(COG), and the theatre of operations. Due to the frequency of 
change and the variability of these addresses, any attempt to 
automate the choice of these would quickly be in error. 

If your requisition involves COG material that falls in 
special categories, the program will warn you and direct you 
to one of the references. 

endtext 

■> 

wait 

@ 3,0 clear 

do case 

case (BPROD = "4E") .OR. (BPROD = "8E") 
text 

** Your requisition is for Air Launched Missile Material 
(COG 4E or 8E), refer to CINCPACFLTINST 8010.12, section 
1, App. 4 or App. 9^HARP00N) or CINCLANTFLTINST 8010. 4H 

endtext 

case BPROD = "8T" 
text 

** Your requisition is for Surfaced Launched Guided 
Missile Material (COG 8T), refer to CINCPACFLTINST 
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8010.12 section 1, App. 7 or CINCLANTFLTINST 8010. 4H 
endtext 

case BPROD = "4T" 
text 

** Your requisition is for torpedoes and components or 
ASROC and components (COG 4T) , refer to 
CINCPACFLTINST 8010.12 section 1, App. 5 or 
CINCLANTFLTINST 3010. 4H 

endtext 

case BPROD = "8S" 
text 

** Your requisition is for SUBROC material (COG 8S), 
refer to CINCPACFLTINST 8010.12 section 1, App. 5 
or CINCLANTFLTINST 8010. 4H 
endtext 

case BPROD = "8U" 
text 

** Your requisition is for sonobouy material (COG 
8U), refer to CINCPACFLTINST 8010.12 section 1, 

App. 8 or CINCLAI'ITFLTINST 8010. 4H 
endtext 

case BPROD = "2D" 
text 

** Your requisition is for Tomahawk material (COG 
2D), refer to CINCPACFLTINST 8010.12, section 1, 
App. 10 or CINCLANTFLTINST 8010. 4H 
endtext 

case BPROD = "6T" 
text 

** Your requisition is for mine material (COG 6T) , 
refer to CINCPACFLTINST 8010.12 section 1, App. 6 
or CINCLANTFLT 8010. 4H 
endtext 

case (BPROD = "2T") .OR. (BPROD = "2E") 
do while .T. 

store " " to BCHOICE 

@ 5,5 say "Is your requisition for mine material? (Y/N) " ; 

get BCHOICE picture "!" 
read 
do case 

case BCHOICE = "Y" 

@7,0 clear 
text 

** Refer to CINCPACFLTINST 8010.12 section 1, 

App. 6 or CINCLANTFLTINST 8010. 4H 
endtext 
exit 

case BCHOICE = "N" 

@ 4,0 clear 
text 

** Your requisition is for normal conventional 
ammunition (Cog 2T or 2E(air)). Your "normal" 
requisition action and info addees are; 



Pacific Fleet Atlantic Fleet 

EastPac MidPac WestPac 



Conus Ord. Activity 
SPCC or DAAS 
(message) 


Ord. Activity 
SPCC or DAAS 
(message) 




TYCOM 


TYCOM 




COHNAVLOGPAC 


COMNAVLOGPAC 




ISIC 


CTF SEVEN THREE 




LOADOUT ACTIVITY 


ISIC 
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LOADOUT ACTIVITY! 



Ref: CINCPACFLTINST 8010.12 section 1, App. 3 
CINCLANTFLTINST 8010. 4H 

endtext 

exit 

otherwise 

waif'Not valid selection, press a key" 
@ 5,0 clear 

endcase 

enddo 

endcase 

wait 

******* End of special addressing info. 

CollsCting Addr6SSeS 

if REQNO = 1 

store space(35) to ADDRESl , ADDRES2 ,ADDRES3 ,ADDRES4 , ; 

ADDRESS ,ADDRES6 , ADDRES7 ,ADDRES8,ADDRES9 



do while .T. 

clear 

d 1,10 to 3,60 double 

@2,15 say "Message Action and Info. Addees" 

? 

text 

Enter the appropriate addresses in the order you wish them to 
appear on the message. Use the cursor keys to move around and 
edit. Address format: ACTIVITY LOCATION 
endtext 
@ 7,0 to 7,79 

if CHOICE = 2 

ADDRESl = "SPCC Mechanicsburg, PA." 

endif 

if CHOICE = 3 

ADDRESl = "DAAS Dayton OH." 

endif 



@ 

@ 

@ 

@ 

@ 

@ 

@ 

@ 

@ 

@ 



9.15 say 

10.15 say 

11.15 say 

13.15 say 

14.15 say 

15.15 say 

16.15 say 

17.15 say 

18.15 say 



Action Addressee: 



Info. Addressee: 



19,0 to 19,78 



1 . 

2 . 

3. 

1 . 

2 . 

3. 

4. 

5. 

6 . 



get ADDRESl 
get ADDRES2 
get ADDRES3 
get ADDRES4 
get ADDRESS 
get ADDRES6 
get ADDRES7 
get ADDRESS 
get ADDRES9 



do while .T. 

store " " to DCHOICE 

@20,2 say "(R)Review address file (S)Save (M)Modify; 

3 d ds 6 s C X ^ 1 ^ ^ 

@ 21,10 say "Enter choice: " get DCHOICE picture "!" 
read 

do case 

case DCHOICE = "R" 
do REVWADD 
select A 
exit 

case DCHOICE = "M" 
exit 

case DCHOICE = "S" 
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exit 

case DCHOICE = "X" 
exit 

otherwise 

@ 22,10 say "Invalid selection.." 
wait 

@ 20,0 clear 
endcase 

enddo 

if DCHOICE = "S" .OR. DCHOICE = "X" 
exit 
endif 

enddo 

if DCHOICE = "X" 
loop 
endif 

endif 

Collecting Addresses********* 

:rxA*x7C!^x7t**:ic(;]_332if ication Determination********** 
if REQNO = 1 
clear 

store " " to CLASS 

@ 0,10 to 2,60 double 

@1,15 say "Message classification information" 
text 

A DAAS formatted message is always UNCLASSIFED because none 
of the MILSTRIP data elements contain classified 
information. 

NOTE: Other technical or operational information about a 

particular item may be classified however, such as 
for torpedoes, some missiles and rockets , etc . . 

A narrative message is likewise UNCLASSIFIED unless you 
must add a REMARKS paragraph that contains classified 
information such as ship's schedule or other operational 
information. 

NOTE: CINCLANTFLT does not permit classified requisitions. 

A separate classified message is required. 

endtext 



do while .T. 

store " " to ECHOICE 

@19,5 say "Will you require a classified REMARKS paragraph; 
?(Y/N)" get ECHOICE picture "!" 

read 

if ECHOICE = "Y" 

@ 22,10 say "Enter the classification of the remarks:" 
get CLASS picture "!!!!!!!!!!!!" 
read 
exit 



else 

if ECHOICE = "N" 

CLASS = "UNCLAS" 
exit 



else 

@ 22,10 say "Invalid entry, press any key.." 
wait" " 

@ 19,0 clear 
endif 
endif 

enddo 

endif 

*xx*x7c**xx*** End Classification Determination ********* 
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********** of common information ************* 
endif 



********** Printing the message worksheet ******** 
if CHOICE = 2 



if REQNO = 1 



clear 

@5,5 say "Ensure the printer is on and the paper aligned to" 
@6,5 say "start printing at the top of a sheet" 

waif'Press any key to start printing" 
clear 

@ 10,10 say "Printing message requisition" 

@ 11,10 say "Please do not disturb until return to menu.." 

@ 9,5 to 12,60 double 
set device to print 

@1,5 say "Ammunition Requisition Message Worksheet" 

@2,5 say "Security classification = "+CLASS 
@3,10 say "LMF = TT CIC = ZYUW" 

@ 4,0 say " 



@6,12 say "From: "+LPR0D 
@7,14 say "To-. "+ADDRES1 
if ADDRES2 <> " " 

@ prow()+l,18 say ADDRES2 
endif 

if ADDRES3 <> " " 

@ prow()+l,18 say ADDRESS 
endif 

@ prow()+l,12 say "Info: "+ADDRES4 
if ADDRES5 <> " " 

@ prow()+l,18 say ADDRES5 
endif 

if ADDRES6 <> " " 



@ prow()+l,18 say ADDRES6 
endif 

if ADDRES7 <> " " 

@ prow()+l,18 say ADDRES7 
endif 

if ADDRES8 <> " " 

@ prow()+l,18 say ADDRES8 
endif 

if ADDRES9 <> " " 



@ prow()+l,18 say ADDRES9 
endif 



@ prow()+2,0 say trim(CLASS) 

@ prow( ) ,pcol( )+l say "//8012//" 

@ prow()+l,0 say "Subj: AMMO MILSTRIP REQUISITION" 
endif 



if REQNO > 1 
clear 

@ 10,15 say "Printing, do not disturb" 

@9,5 to 11,40 double 
set device to print 
endif 

@ prow()+2,0 say ltrim(str(REQNO) ) +" . " 

if CLASS <> "UNCLAS" 

@ prow(),pcol() say "(U) " 

endif 

@ prow(),pcol() say DOCIDENTIF+"/"+ZPROD +"/"+MEDIASTAT +"/" 

store 1 to MARK 
store " " to tempi 

store " " to temp2 
store " " to POSIT 



II 
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tempi = ltrim(str(APROD) ) 



do while MARK < 5 

temp2 = substr(templ ,MARK, 1) 

do SPELLIT with temp2, POSIT 
© prow(),pcol() say Itrim(POSIT) 
MARK = MARK + 1 
enddo 



+ " 



II 



store 1 to MARK 

do while MARK <10 

temp2 = substr(NIIN, MARK, 1) 
do SPELLIT with temp2, POSIT 
if MARK = 7 

© prow()+l,0 say Itrim(POSIT) + " " 
endif 

© prow( ) ,pcol( ) say Itrim(POSIT) + " " 

MARK = MARK + 1 
enddo 

© prowO ,pcol()-l say ''/"+CPROD +"/" 

store 1 to MARK 

do while MARK < 6 

temp2 = substr (QUANTITY, MARK, 1) 
do SPELLIT with temp2, POSIT 
© prow( ) ,pcol( ) say Itrim(POSIT) + " " 

MARK = MARK + 1 
enddo 

© prowO ,pcol()-l say "/"+JPROD+KPROD+"/"+JULIANDATE+"/"+; 
ltrim(str(SERIAL))+"^'+DEMANDCODE+"/"+chr(10) 

© prowO, 0 say SUPADDSERC+SUPADDUIC+"/"; 
+SIGNALCODE+"/"+NPROD+"/"+OPROD+BPROD+; 

"/"+PROJCODE+"/"+PRIORITYCD+"/"+REQDELDATE+'7"+ADVICECODE+chr(10) 

set device to screen 

clear 

^7^-k-k Determine if more messages will be printed 
text 

Choose one: 1. More message requisitions to print with 

same addresses and classification. 



2. More message requisitions to print with 

different addresses and/or classification. 

3. Add narrative remarks paragraph 

4. Finished message requisitions 

endtext 



store 0 to GCHOICE 

© 12,15 say "Enter Choice: " get GCHOICE picture "9" range 1,4 
read 



do case 

case GCHOICE = 1 
REQNO = REQNO + 1 
clear 

© 5,5 say "Do not advance printer, next" 

© 6,5 say "requisition will print as paragraph" 
© 7,5 say "2, 3, etc. ." 

wait 



case GCHOICE = 2 
clear 

set device to print 
© prow()+2,0 say "BT"+chr(10) 
set device to screen 

© 5,5 say "Remove previous message worksheet" 
© 6,5 say "from printer, set up tor the next" 
© 7,5 say "printed message worksheet" 
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REQNO = 1 
wait 

case GCHOICE = 3 

store space (254) to COMMENTS 
clear 

@5,5 say "Enter remarks: " get COMMENTS 
read 

set device to print 

@ prow()+2,0 say ltrim(str( (REQNO +1)))+". " 
if CLASS = "CONFIDENTIAL" 

0 prow() ,pcol() say "(C) " 
endif 

if CLASS = "SECRET" 

0 prow( ) ,pcol( ) say "(S) " 
endif 

0 prow() ,pcol() say "Remarks: "+ trim (COMMENTS) 

0 prow()+2,0 say "BT"+chr(10) 
set device to screen 

REQNO = 1 
clear 



case GCHOICE = 4 
REQNO = 1 
clear 

set device to print 
0 prow()+2,0 say "BT"+chr(10) 
set device to screen 



endcase 



endif 



***** Process DAAS formatted message ************** 

if CHOICE = 3 
if REQNO = 1 

clear 

0 0,15 to 2,50 double 
0 1,20 say "DAAS message information" 

■> 

text 

The Defense Automated Addressing System(DAAS) is a real-time 
telecommunications system located in Dayton, OH. which is 
designed to effectively route logistics traffic to supply 
sources. DAAS messages are submitted in a fixed, machine - 
readable format which does not have to be transcribed for 
entry into the CAIMS sytem as do narrative messages or manual 
requisitions . 

'k'k'k'k'k'k'k'k'k'k'k'k MESSAGES 

1. Must be UNCLASSIFIED. 

2. Must not require REMARKS. 

3. Must be to CONUS activities only. 

4. Must not be for CV loadouts from AOE/AE. 
endtext 

0 10,5 to 16,62 double 
text 

For more information on DAAS read: NAVSUP Pub 485, section 
3028, SPCCINST 8010. 12D, section 8-207, CINCPACFLTINST, 
section 1-5 or CINCLANTFLTINST 8010. 4H, section 
endtext 

do while .T. 

store " " to HCHOICE 

0 21,5 say "Is DAAS format still O.K.?(Y/N)" get HCHOICE 
picture "!" 
read 



do case 
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case HCHOICE = "Y" 
clear 
exit 

case HCHOICE = "N" 
clear 
exit 

otherwise 

@ 23,10 say "Invalid entry, press any key.." 
wait" " 

0 21,0 clear 

endcase 



enddo 

if HCHOICE = "N" 
loop 
endif 

0 5,5 say "Ensure the printer is on and the paper aligned" 
0 6,5 say "to start printing at the top of a sheet." 

wait"Press any key to start printing" 
clear 

0 10,10 say "Printing DAAS message requisition--" 

0 11,10 say "Please do not disturb until return to menu." 

0 9,5 to 12,60 double 
set device to print 

01.5 say "DAAS Requisition message worksheet" 

02.5 say "Security classification = UNCLAS" 

0 3,10 say "LMF = XT CIC = ZYUW " 

0 4,0 say " " 

0 6,12 say "From: "+LPR0D 
0 7,14 say "To: "+ADDRES1 
if ADDRES2 <> " " 

0 prow()+l,18 say ADDRES2 
endif 

if ADDRES3 <> " " 

0 prow()+l,18 say ADDRES3 
endif 

0 prow()+l,12 say "Info: "+ADDRES4 
if ADDRESS <> " " 

0 prow()+l,18 say ADDRESS 
endif 

if ADDRES6 <> " " 

0 prow()+l,18 say ADDRES6 
endif 

if ADDRES7 <> " " 

0 prow()+l,18 say ADDRES7 
endif 

if ADDRES8 <> " " 

0 prow()+l,18 say ADDRES8 
endif 

if ADDRES9 <> " " 

0 prow()+l,18 say ADDRES9 
endif 

0 prow()+l,0 say "Subj .- AMMO MILSTRIP REQN." 
endif 



if REQNO > 1 
clear 

0 10,15 say "Printing, do not disturb." 

0 9,10 to 11,45 double 
set device to print 
endif 

if REQNO = 1 

0 prow()+4,5 say DOCIDENTIF+ZPROD+MEDIASTAT+ ? 
ltrim(strrA?.ROD))+NIIM+" "+CPROD+QUANTITY+JPROD+KPROD+; 
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JULIANDATE+ltr im( s tr ( SERIAL) ) +DEMANDCODE+SUPADDSERC+ ; 

SUPADDUIC+SIGNALCODE+NPROD+OPROD+BPROD+PROJCODE+; 

PRIORITYCD+REQDELDATE+ADVICECODE+chrUo) 

endif 

if REQNO > 1 

(? prow()+l,5 say DOCIDENTIF+ZPROD+MEDIASTAT+; 
ltrim(str(APROD) )+NIIN+" "+CPROD+QUANTITY+JPROD+KPROD+ ; 
JULIANDATE+ltrim(str (SERIAL) )+DEMANDCODE+SUPADDSERC+ ; 
SUPADDUIC+SIGNALCODE+NPROD+OPROD+BPROD+PROJCODE+ ; 
PRIORITYCD+REQDELDATE+ADVICECODE+chr ( 10 ) 

endif 



set device to screen 
clear 

*”****** Determine if more requisitions on same message** 
text 

Choose one: 

1. More requisitions to print with same 

action and info, addresses. 

2. More requisitions to print with different 

action and/or info, addresses. 

3. Finished DAAS message requisition. 

endtext 



store 0 to ICHOICE 
@ 12,15 say "Enter choice: 

read 



" get ICHOICE picture "9" 
range 1,3 



do case 



case ICHOICE = 1 
REQNO = REQNO + 1 
clear 

@ 5,5 say "Do not advance printer, next" 
d 6,5 say "requisition will print below" 
@7,5 say "previous one." 

7 

wait 

case ICHOICE = 2 
clear 

@5,5 say "Remove worksheet from printer, 
@6,5 say "set up paper for next message. 

REQNO = 1 
wait 

case ICHOICE = 3 
clear 
REQNO = 1 

endcase 

endif 



********* DAAS formatted message ************** 
enddo 

close databases 
clear all 
return 
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9. PROGFILE.PRG 



^ PROGFILE.PRG 

^ This program reviews the system program file and prints it if 
^ desired. 

Written by LT. Steven L. Smith, USN 13 July, 1987 

^ Activate next two items if program used alone, 
set talk off 
set status off 
set bell off 

lear 

5,15 say "S.AMS Proaram File" 

4,10 to* 0,45 double 



■> 

text 



endtext 



What would you like to do? 

1. Review the program file 

2. Print the program file 

3. Quit 



store 0 to ITEM 

@ 20,10 say "Enter choice: " get ITEM picture "9" range 1,3 
read 

do case 

case ITEM = 1 
clear 

use PROGFILE index PROGNAME 
do while .T. 



store 1 to MLINE 
store 1 to MCOUNT 

do while (MCOUNT <=3) .AND. (.NOT. eof()) 

0 MLINE, 5 say "Program Name; "+PROG_NAME 
0 MLINE+1,5 say "Calls: "+rtrim(CALLS ) 
0MLINE+3,5 say "Purpose: "+rtrim(PURPOSE) 
0 HLINE+5,5 say "Called by: "+rtrim(CALLED_BY) 
0 MLINE+6,0 to MLINE+6,78 

MLINE = MLINE + 7 
MCOUNT = MCOUNT + 1 
skip 

enddo 

if eof() 

0 23,60 say "End of File" 
endif 

do while .T. 

store " " to CHY 

0 22,5 say "(C)Continue (R)Repeat (X)Exit: " ; 
get CHY picture "!" 
read 

do case 

case CHY = "C" .OR. CHY = "R" 
if eof() 

goto top 
endif 
exit 

case CHY = "X" 
use 
clear 

set talk on 
set status on 
set bell on 
return 
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otherwise 

(§ 23,5 say "Invalid selection, press a key-" 
wait" " 

@ 22,0 clear 

endcase 

enddo 

clear 

enddo 



case ITEM = 2 
clear 

@ 10,10 say "Printing, do not disturb" 
@ 9,5 to 11,37 double 
use PROGFILE index PROGMAME 
set device to print 



@ prow() , 0 say 
@ prow( ) ,0 say 



@1,15 say "SAMS Program File"+chr (10) 
"+chr ( lOl 

11 

"+chr(10) 



do while .NOT. eof() 



@ prow()+2,5 sa 
d prowH , 5 say 
0 prow( ) , 5 say 
§ prow( ) , 5 say 
@ prow(),0 say " 



y "Program Name: "+PROG_NAME+chr(10) 
^'Calls: "+CALLS+chr(10) 

"Purpose: "+PURPOSE+chr(10) 

"Called by: "+CALLED_BY+chr(10) 

"+chr(10) 



skip 

enddo 



use 

set device to screen 



case ITEM = 3 
clear 

@ 10,10 say "Quit this program" 

use 

wait 

set talk on 
set status on 
set bell on 
return 



endcase 

set talk on 
set status on 
set bell on 

return 



10. REQ1348.PRG 

* REQ1348.PRG 

* Program to display replica of DD Form 1348 filled in 

* Written by LT. Steven L. Smith, USN 16 June, 1987 
clear 



@ 

0 

0 



1, 3 SAY SENDTOSERC 

1, 4 SAY SENDTOUIC 

1, 10 SAY FPROD 

if SENDTOSERC = "V" .OR. SENDTOSERC 
0 2, 13 say YPROD 

else 



"Rtl 
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endif 

(? 1, 40 

@ 1, 41 

@ 1, 48 

@ 2, 45 

@5,2 
@ 5, 25 

@ 5, 30 

@ 5, 36 

@ 5, 40 

@ 5, 49 

@ 5, 62 

@ 5, 67 

@ 5, 71 

@3,2 
@8,3 
@ 7, 40 

@ 8 , 11 
@ 3, 17 

@ 8, 23 

@ 8, 27 

@ 8, 28 
@ 3,36 

@ 11 , 2 
@ 11 , 6 
@11, 7 

@ 11, 10 
@ 11, 14 
@ 11, 17 
@ 11 , 21 
@ 14, 2 

@ 14 , 6 

@ 16, 16 
@3, 2 

@ 6 , 2 
@ 9 , 2 

@ 12 , 2 
@0,1 
@ 1, 33 

@ 7, 38 

@ 4, 35 

@ 4, 29 

@ 4, 24 

@ 4,15 

@ 4, 70 

@ 4, 65 

@ 4, 45 

@ 4, 61 

@ 7, 35 

@ 7, 24 

@ 7, 21 

@ 10, 20 
@ 10, 16 
@ 10, 13 
@ 10, 9 

@ 10, 5 

@13, 5 

@ 13, 33 
@ 13, 29 

return 



@ 2, 12 say GPROD 

SAY JPROD 
SAY KPROD 
SAY LPROD 
SAY MPROD 

SAY "XXXXXXXXXXXXX XXXXXXXX" 

SAY AMREQUIS->DOCIDENTIF 
SAY ZPROD 

SAY AMREQUIS->MEDIASTAT 
SAY ltrim(str(APROD) ) 

SAY AMREQUIS->NIIN 
SAY "XX" 

SAY CPROD 

SAY AMREQUIS->OUANTITY 
SAY JPROD 
SAY KPROD 
SAY "Remarks:" 

SAY AMREQUIS->JULIANDATE 
SAY AMREQUIS->SERIAL 
SAY AMREQUIS->DEKANDCODE 
SAY AMREOUIS->SUPADDSERC 
SAY AMREQUIS->SUPADDUIC 
SAY AMREQUIS->SIGMALCODE 
SAY NPROD 
SAY OPROD 
SAY BPROD 

SAY AMREQUIS->PROJCODE 
SAY AMREQUIS->PRIORITYCD 
SAY AHREQUIS->REQDELDATE 
SAY "XXXXXXXXXXXXXXXXX" 

SAY AMREQUIS->ADVICECODE 

SAY " XXXXXXXXXXXXXXXXXXXXXXXXXXX" 

SAY "DD Form 1348 - Manual Requisition" 
TO 3, 77 
TO 6, 77 
TO 9, 77 
TO 12, 77 

TO 15, 73 DOUBLE 

TO 5, 38 

to 11,38 double 

TO 5, 35 

TO 5, 29 

TO 5, 24 

TO 5, 15 

TO 5, 70 

TO 5, 65 

TO 5, 45 

TO 5, 61 

TO 8, 35 

TO 8, 24 

TO 8, 21 

TO 11, 20 

TO 11, 16 

TO 11, 13 

TO 11, 9 

TO 11, 5 

TO 14, 5 

TO 14, 33 double 

TO 14, 29 
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II. REQMENU.PRG 

*REQMENU.PRG 

*Program to present the Requisition Management Menu 
^Written by lT. Steven L. Smith, USN , 6 June, 1987 

Clear all 



do while .T. 



clear 

text 

Requisition Management Menu 

1. Review all requisitions - Summary 

2. Review complete requisition data 

3. Create a new requisition 

4. Edit and delete requisitions 

5. Cancellation^ Follow-up, Modifications, Info 

6. Print requisition documents 

7. Backup Requisition File 

99. Return to Main Menu 

endtext 

0 1,0 to 21,79 double 
0 3,1 to 3,78 
0 18,1 to 18,78 

store 0 to MSELECT 

0 19,22 say "Enter your selection: " get MSELECT picture "99" 
read 

do case 

case MSELECT = 1 
do REVWREQ.PRG 

case MSELECT = 2 
do COMPLREQ.PRG 

case MSELECT = 3 
do CRENEWRQ.PRG 

case MSELECT = 4 
do EDITREQ.PRG 

case MSELECT = 5 

do MISCREQ.PRG 

case MSELECT = 6 

do PRINTREQ.PRG 

case MSELECT = 7 

do BCKUPREQ.PRG 

case MSELECT = 99 
return 

othe rwise 

0 22,16 say "Not a valid selection--" 

wait " Press any key to try again 

endcase 

enddo [.T.] 
clear all 
return 
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12. RE\'\VADD.PRG 



* REVWADD.PRG 

* This orogram reviews the address file (library module) 

* Written by LT. Steven L. Smith, USN 20 June, 1937 

* NOTE: If used external to AMSMAIN, activate next two lines. 

* set status off 
set talk off 

clear 

@ 1,15 to 3,55 double 
@2,23 say "Address File" 

@ 5,0 say "S/C UIC ACTIVITY LOCATION 

.HULL NO. R/I" 

@ 6,0 to 6,79 
select H 

use ANDADDR index AMDACTNM 



do while .T. 

store 1 to MCOUNT 
store 3 to MLINE 

do while (MCOUNT <= 10) .AND. (.NOT. eof()) 

@ MLINE ,1 say SERVCODE 
@ MLINE ,3 say UIC 
@ MLINE ,10 say ACTIVNAME 
@ MLINE ,35 sav LOCATION 
@ MLINE ,62 say HULLNUMBER 
@ MLINE ,73 say ROUTIDENT 

MLINE = MLINE + 1 
MCOUNT = MCOUNT + 1 
skip 

enddo 

if eof() 

@ 20,50 say "End of File" 
endif 

do v/hile ,T. 

store " " to ZCHOICE 

@ 21,5 say " (C)Continue , (R)Repeat, (X)Exit:" get ZCHOICE; 
picture "!" 
read 

do case 

case ZCHOICE = "C" .OR. ZCHOICE = "R" 
if eof() 

goto top 
endif 
exit 

case ZCHOICE = "X" 
use 
clear 
return 

otherwise 

@ 22,20 say "Invalid selection, press any key to try again-" 

wait " " 

@ 21,0 clear 

endcase 



enddo 

@ 7,0 clear 



enddo 

use 

return 
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13. REWREQ.PRG 

* REVWREQ.PRG 

Program to quickly review the requisition file 

* Written by LT. Steven L. Smith, USN 13 June, 1987 

clear all 
select A 

use AMMODATA index AMANIIN 
select E 

use AMREQUIS index AMRSERDW,AMRSERUP,AMRREQDD 
set relation to NIIN into AMMODATA 



clear 

@ 1, 22 to 3, 49 double 
@ 2, 27 say "Requisition File" 

@ 5,4 say "SERIAL NALC NIIN SHORT TITLE 

QUANTITY STATUS J/DATE " 



set heading off 
goto top 

do while .T. 

@1, 0 to 24, 79 double 
0 6, 1 to 6,78 
store 7 to mline 
store 0 to xcount 

do while (.not. eof()) .AND. (xcount < 10) 

0 mline, 5 say SERIAL 
0 mline, 13 say A->NALC 
0 mline, 19 say NIIN 
0 mline, 30 say A->SHORTTITLE 
0 mline, 55 say QUANTITY 
0 mline, 65 say REQUISSTAT 
0 mline, 73 say JULIANDATE 

mline = mline + 1 
xcount = xcount + 1 



enddo 



skip 

if eof() 

0 la, 5 say 
endif 



"That's all the requisitions on file:" 



do while .T. 

store " " to CHOICE 

0 20,5 say "Want to see more or review again? (Y/N) " ; 
get CHOICE picture "!" 
read 

do case 

case CHOICE = "N" 
set heading on 
clear all 
return 

case CHOICE = "Y" 
if eof() 

goto top 
06, 0 clear 
exit 
else 

0 6, 0 clear 
exit 
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endif 

case CHOICE <> "N” .AND. CHOICE <> "Y" 
021,5 say "Not a valid choice--" 
wait" Press anv key to try again-" 
0 19, 1 clear to 23,73 

endcase 

enddo 

er.ddo 
clear all 
return 



14. SPELLIT.PRG 

Procedure SPELLIT 

^ This program returns a soelled out character string for the 
character number 

Written by LT. Steven L. Smit.h, USN 20 June, 1987 

procedure SPELLIT 
parameters te.mp2, POSIT 

do case 

case temp2 = "9" 

store "MINE" to POSIT 
case temp2 = "8" 

store "EIGHT" to POSIT 
case temo2 = "7" 

store "SEVEN" to POSIT 
case temp2 = "6" 

store "SI.X" to POSIT 
case temp2 = "5" 

store "FIVE" to POSIT 
case temp2 = "4" 

store "FOUR" to POSIT 
case temp2 = "3" 

store "THREE" to POSIT 
case temp2 = "2" 

store "TWO" to POSIT 
case temp2 = "1" 

store "ONE" to POSIT 
case temp2 = "0" 

store "ZERO" to POSIT 

endcase 



return 



15. STRUCCRT.PRG 



^ STRUCCRT.PRG 

This program displays the SAMS structure charts 
* Written by LT. Steven L. Smith, USN 13 July, 1987 

clear 

set talk off 
set status off 

10,20 say "SAMS Structure Charts" 

8,15 to 12,46 double 

20,10 say "Press any key to start viewing charts--" 
wait" " 
clear 

do v;hile .T. 



text 



Shipboard Ammunition Management System 
Major Sub-system Structure Chart 
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AMSMAIN 



TRANMENU REQMENU TURNMENU NARSMENU 

, INVKENU MANGMENU 



INFOMENU 



REPTMENU 



endtext 

v/ait 

clear 

text 

User Access/Main Menu 



PROTECT 



AMSMAIN 



endtext 

wait 

clear 

text 

General Information/Documentation 



INFOMENU 



INFOHELP 


DOCCODES 


DOCDEFIN 


DOCREFS 


INFOTEXT 






DATAELEM 



endtext 

wait 

clear 

text 

Inventory/Allowance/Ammunition Information 



INVMENU 
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INWIEW 



INVAMMO 



INVALLOW 



endtext 

wait 

clear 

text 

Requisition Management 



REQMENU 



REVWREQ COMPLREQ CRENEWREQ EDITREQ MISCREQ 



endtext 

wait 

clear 

text 



PRINTREQ BCKUPREQ 



REQ1348 REVWADD SPELLIT 



Transaction Management 



TRANMENU 

I ' 

I I 

VIEWATR CRENWATR EDITATR BCKUPATR PRINTATR 

REVWADD 



endtext 

wait 

clear 

text 

Generate Internal Reports 



IWREPT OSRQREPT 



REPTMENU 



TRALREPT Other Reports 
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endtext 

wait 

clear 

text 

NARS Management 



NARSMENU 



REVNARSF REVNARAF PROCNAR BCKUPNAR 



endtext 

wait 

clear 

text 

Turn-in Document Management 



TURNMENU 

^ I ' ^ 

TURNREV BCKUPTUR CRENWTID EDITTURN PRINTTUR 

REVWADD 



endtext 

wait 

clear 

text 

System Management 



MANGMENU 

I ^ 

MANGSEC MANGARCH 
. HANGED IT 

BCKUPSYS DOCFlLES PROGFILE STRUCCRT 



MANGRECV MANGADHC MANGINIT 
HANGDOG 



endtext 

wait 

clear 

do while .T. 
store " " to XYZ 

@5,5 say "Do you wish to review the charts again? (Y/N) " ; 
get XYZ picture "!" 



180 



read 
do case 

case XYZ = "Y'‘ 
clear 
exit 



case XYZ = "N” 
clear 

set talk on 
set status on 
exit 

otherwise 

@10,5 say "Invalid entry, press a key- 
wait" " 

@ 5,0 clear 

endcase 



enddo 

if XYZ = "N" 
exit 
endif 



nddo 

eturn 
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